Is there an idiomatic way to do dynamic queries with a defrouter? I understand that the right way to do dynamic queries is to use a factory with a qualifier, rather than a component. AFAIK, defrouter works exclusively with components.

@levitanong Did you take a look at http://book.fulcrologic.com/#_code_splitting_modules ?

@claudiu i have, but it’s a slightly different use case. Consider a component Org, which contains a list of both :org/campaigns and :org/brands. I have a tab which switches between showing campaigns and brands.

Originally I wanted to put both campaigns and brands in separate routes, but because they’re properties of an entity, it’s difficult/impossible to come up with some sane way to ident the components to route to

So I figured I should use set-query!. Clicking on the campaigns tab sets the query to ask for :org/campaigns.

likewise for brands

hmmm, I used the dynamic one just because I wanted code splitting. Can't you get what you want by nesting two defrouters. One for the page screen and another one for the tab view ?

@claudiu because it’d be an Org inside an Org 😛

That said, it seems to work if I don’t add a :qualifier, but I’m not sure that’s safe

🙂

I use showdown js package from http://cljsjs.github.io/ , but when i change my input on text area, the markdown won't change.

@levitanong no qualifier is needed if it is a singleton

without a qualifier the instance queries will change together based on the class

Also, understand that the defrouter is both an optimization and an implementation...it uses union queries, which makes your app faster. In some cases it makes perfect sense to just code a component that has a normal queury, and "routes" via if-like logic

they query will be a little more overhead that way, but in some cases that will be fine and the logic will be easier...I lean towards that before a dynamic query, personally

but the dynamic query case is good if you have large queries under each possible "route"

@tony.kay Oh, great! Glad to know about the singleton bit. That makes sense. As a learning exercise, I’ll use the dynamic queries (I have the leeway to do this since i’m writing a small internal application) and if i run into trouble, I’ll go with the normal query with conditionals 🙂 Thanks for the help!

@veddha.riady why are you using an atom on line 16?

the problem is react re-render is not being triggered, and that only happens when app state (and query data change)

but you’re storing data out side of app state, fulcro has no idea about it

if you put everything in app state you’ll see it change

Is there a way to run a mutation, of change the state directly, after a nav-to! call as implemented in the fulcro template? I’m trying to avoid flickering of the UI upon visiting a non-login route

@pvillegas12 i believe all the routing mutations have helper functions that can be composed into one of your mutations, so then all changes happen atomically in one mutation, that should avoid flicker

these helper functions are part of the public API