it took me awhile to figure out, so it might help if it was explicitly written somewhere https://clojurians.slack.com/archives/C68M60S4F/p1591001710281000?thread_ts=1590933761.263300&channel=C68M60S4F&message_ts=1591001710.281000

@fjolne.yngling this is not a true statement

your problem @mroerni is that you probably don't have any state in that node in the graph.

the order of the query may make some strange difference in the case when you have not reified your graph properly, but it isn't meant to be a "supported" use-case that you have to order it to get it to work.

The problem is that the query will not descend into a component that has no explicit edge in the data graph. If you only query for some "other component's state" and have none of your own, then it will not work. This is an unfortunate consequence of reified views: if it isn't reified (in the data model), then it isn't there....but technically you can still call a function to render it. I have yet to think of a great way to solve that in a general way. You can use "floating roots" if you want to disconnect two sub-trees, but each node still has to have reified data.

TL;DR: Add :initial-state {} to your component, and make sure the parent composees initial state to itself.

that will create the reified edge

This could be it. The node is under a router. It has an :initial-state -

But the issue resolved itself… It somehow it started to behave like expected.

perhaps you had not reloaded after adding one of those things

initial state only happens on initial mount

and the dynamic queries (used by the routers) also need initialization with a reload.

@tony.kay hm, does that mean that the target is supposed to be a singleton? I have many targets which naturally doesn’t have initial state, and dynamic routing works fine for them except for the first render with dr/current-route on their parent, which is actually not about being the first, but about dr/current-route lagging behind in time (so that timeout would fix it)

The target does not have to be a singleton, no…but such things are loaded, and you do have to be careful about execution order in that case.

so, no initial state in that case, but they must not be your initial route in that case

i.e. they should not be first in the list of targets on a router that is in the initial “route”

current-route has to use the reified graph and queries to figure out what is “on screen”…so it is time-sensitive

yep, the issue is in this line, but you have fallback to the first query child which fixes it https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/routing/dynamic_routing.cljc#L292

In the case above, the thing to note is that nothing was in the query except an ident…a case that commonly hurts ppl because they forget to give that node state of its own

ah, I see. Correct, if there is not a component on-screen, then we have to assume that the route is “going to be” the default one listed in the router

It’s been a while since I wrote that code, and it may not be the ideal way of answering the query. Using the on-screen index isn’t ideal in this case, and it would probably be better to use the dynamic query and current state. There will always be, however, timing issues around changing a route and what you “see” from this function call to ask “where are we?“.

That is a product of the features like “will enter” and route denial.

I cannot synchronously change the state to the new route.

so it will always be the case that current-route lags a call to change-route

That said: dynamic router has some rough edges still, and deserves more attention. I just do not have the time. It could use: • Better rendering logic to prevent route flickering. The routers should probably auto-coordinate to prevent anything from changing until everything is stable. This is kinda hard, and might even be the wrong thing to “always do”…since routers in the path might want fine-grained control. • More helpers, like pending-route to go with current-route The RAD helpers add some useful stuff, but I’ll probably leave those in RAD.

well, to be honest, I’m just not sure why router should care about what’s on screen and what’s not, and why it couldn’t be just a function of its state machine. I often fallback to legacy router because of its simplicity (especially when I don’t have natural URL segments for targets), dynamic router makes it really hard to reason about in more complex scenarios

Is it generally supported to have a subcomponent use a root link query? I'm seeing a parent component get the data properly using: {[:all-users '_] (comp/get-query User)} but rendering a nested list component {:user/list (comp/get-query UserList)} which does the same link join receives no data

@danvingo it is, but subcomponent should have it’s own state, not just a link query

thanks. I have the state map to support the nested link. The issue I'm seeing is the first render of data works fine. I'm clearing the data after the user logs out and then after a user logs in again the data is loaded and put in the top level of the state map but the link query nested component gets no data

adding or removing an ident on the nested component has no effect

do the nested components have actual data in the state-map?

no, just an empty map

i'm running the same link query in the parent and receiving data at render time, but the child component using the same link query receives nil

yes, that’s because a component with link query should have proper own state http://book.fulcrologic.com/#_a_warning_about_ident_and_link_queries

I have an empty map as initial-state like that example

is that not correct?

depends on ident, what ident nested components have?

it currently doesn't have one

ok, so as far as I understand you use children only for rendering, they don’t have natural state of their own? in this case it seems better to just pass them data from the parent, and have them defined as common React components (not Fulcro ones): (defsc Child [this props] (dom/div ,,,))

it might even make sense to define them as regular functions if they’re simple enough (i.e. don’t require props optimizations)

That would work, and what I might end up doing - I just wanted a List component that I could drop in around the app without needing to wire up the list of data it needs

it works on first render, the issue shows up when i clear the db for logout

and then repopulate

I think i found a solution, - was just playing around with what is proper "empty state" for the subcomponent when the data is reset

i think that did it- i had to set the join property on the parent to {} to get the query working again

on login: set the prop to the nested prop to empty map: [:component/id :my-thing :my-list] {} and insert the top level list of idents that the nested component queries for

i think that makes sense because it is the parallel of what initial-state is doing

thank you @fjolne.yngling rereading that section made me think about what the query resolver is actually doing

i have a related general question - what i'd really like is run initial-state for my app again for a logout + login flow. I don't see a way to do this other than hand curating the state db to some sane initial state. is there a way to issue a "re-run initial state" mutation for the entire app?

@danvingo ah, I thought you were trying to link query from List items, not from the List component itself. if you’re link querying from the List itself, then you don’t really need to set up its state on every mutation: your mutation works because your List doesn’t have an ident, thus its state isn’t normalized and stored inside every component it turns out to be a child of. Something like this should work:

(defsc List [this {:link/keys [data]}]
  {:query         [[:link/data '_]]
   :ident         (fn [] [:component/id :my/list])
   :initial-state {}}
  ,,,)

(def ui-list (comp/factory List))

(defsc Parent [this {:parent/keys [list]}]
  {:query         [{:parent/list (comp/get-query List)}]
   :ident         (fn [] [:component/id :my/parent])
   :initial-state {:parent/list {}}}
  (ui-list list))

thank you, that setup is working now 🙂

but i'm still wondering what's the best practice around resetting a db after an auth reset?

having to build up the state db out of band from the components is not great, that's what get-initial-state is supposed to handle

but i'm not sure of another way

@danvingo of course you can reset state: (reset! (::app/state-atom app) (comp/get-initial-state Root {}))

then just schedule a render

and doing that in a mutation is even easier, as long as you know the root (which you can get from the app…so)

something like:

(defmutation logout [_]
  (action [{:keys [app state]}]
    (reset! state (comp/get-initial-state (app/app-root app) {}))))

oh duhh, that's it!

thank you