Clojurians Log v2

Hey Luis, yep you generally should trigger mutations when an event occurs (user event like click or touch event, or some timer firing, or a router change state)

BUT, a production app won’t have Inspect turned on, so it cannot detect those. You’d only be able to detect apps that were released in “development” mode, which is much slower, and therefore unlikely. Inspect adds quite a bit of overhead to the app (it has to encode states, remember history, etc.)

If you take a look at the internals of RAD defsc-form and defsc-report (the UI state machine, in particular), I’d consider those good examples of how you handle quite a few concerns like that. But as @alex-eberts said: don’t try to run too fast. If you don’t understand the core basics, those internals will probably be a bit much.

Is there going to be performance problems if I don't shrink wrap every query? For example, the Login panel needs two field stored by the ident [:component/id :session], but is it okay if I write

{:query [... {[:component/id :session] (comp/get-query SessionQuery)}]}

A lot of the time, I have a large deep query lying around for a large widget. And I am tempted to use it in quite a few smaller widgets that only uses a tiny sub-tree of this huge query, I wonder if it is okay (or even intended)? I feel like it's very non-ergonomic having to write every slim shrink-wrapped tree for even the smallest widget.

Unrelated: seems that uism/trigger-remote-mutation does not support :without in df/load! (or the underlying df/elide-query-nodes), right? Doesn't this make it impossible to do incremental load with uism?

Doesn't sound maintainable to me as you are coupling 2 unrelated components.. What if Login starts needing a field not requested by Session? Each component should query for (only) the data it needs. If the data is shared, put them to a well-know place in the DB (eg. :ui/current-session, the value can be the data or an ident pointing to the data) and use Link Query to access it from all places that need it.

Though your singleton component you have could also work just fine...

Login queries for whatever props it needs, its parent has the Link/Ident query to connect to the session data.

I have https://blog.jakubholy.net/2020/fulcro-divergent-ui-data/ but perhaps not so helpful here...