i've used pre-merge for this personally, the situation was that i had to initialize some props on every item in a list that wasn't loaded until after app setup. not positive that it's the recommended solution but i can't really think of a better way to init state on a component not present at startup

Thank you o/

That is a correct approach I believe. See eg http://book.fulcrologic.com/#_initial_state_2

are you seeing this on the browser side or the server side?

I'm seeing it in fulcro inspect, and on the browser (seems to flicker?)

specifically what's going on is I have a df/load! in :will-enter -- likely not the right way to do it, but I'm curious if I can track that behavior somehow

if you're using it along with dr/route-deferred that is the standard way to do it. can you share your :will-enter?

should look sth like this for a global pathom query:

(fn [app _]
  (dr/route-deferred
    ident
    #(df/load! app :global-query ProjectListItem
               {:target               (conj ident :my-prop)
                :post-mutation        `dr/target-ready
                :post-mutation-params {:target ident}})))

ah, using route-deferred stops the chatter. I was trying out df/load! followed by route-immediate because it seemed to be substantially more responsive

hm, it is weird that that results in multiple queries. my only guess is that maybe dr internally can cause :will-enter to fire multiple times

:will-enter (fn [app {:keys [view-param]}]                  (let [view-id [:view/id (uuid view-param)]]                    (df/load! app view-id View)                    (dr/route-immediate view-id)))

another way to do it would be to put the load wherever you trigger the route change but i'm not sure if that'd be ergonomic for your case

(and then route immediately in the will enter)

and really, it does still seem to be more responsive. I think I'm doing routing fundamentally wrong somehow because it seems like the new component getting loaded co-exists simulatenously for an instant with the old one

where my routing logic is just calling pushy/set-token! inside a mutation (and I guess pushy calls dr/change-route! in history

yeah I think the router would have to know about the UI components and that seems weird

In general the control of I/O should be in centralized logic, I recommend UISM, and not tied exclusively to the UI component. “Routing” in Fulcro is really meant to be nothing more than “UI query update, render correct thing”. Getting the event from that can trigger I/O of course, but typically your logic needs will surpass the routing concern. E.g. what if you just routed there, went elsewhere, and came back? Reload/caching logic needs its own layer…routing should just be saying “I’m here now” to a more centralized bank of well-designed logic IMO

So if you are thinking of using route-deferred , good time to think up a UISM solution. Is that the general advice?

in a “real app”, it’s what I almost always do…but these days mostly I use RAD’s pre-written UISM machines, so I rarely have to write the logic by hand again.

I’m working on a mobile app this minute, but I have no UI plugin for RAD yet…still, I’m using a defsc-form, which in turn gives me all the routing, loading, saving…all I have to do is write some UI tags.

you typically only have 1-3 patterns in a given type of app…and UISM is designed to not need to know the specifics of UI…UI elements are just actors in the model. So, reuse is quite good.

oh, interesting. I hadn't thought of a webpage as a state in a state machine before, but that makes a lot of sense, especially wrt caching.. another fun fulcro thing to learn. Thanks!

go long on UISMs I say, there's no abstraction like it that i know of in JS frameworks

@U797MAJ8M if you want some real world machines to look at after you're done with the book i found it helpful to look at https://github.com/fulcrologic/fulcro-rad-demo/blob/master/src/shared/com/example/ui/item_forms.cljc and https://github.com/dvingo/my-clj-utils/blob/master/src/main/dv/fulcro_entity_state_machine.cljs. I wrote https://github.com/lgessler/glam/blob/master/src/main/glam/client/ui/common/forms.cljs#L160 too

@U49U72C4V in the JS world Xstate seems popular. They do/require a bit more than UISM's but do get cool visualization features as a bonus.