Fork me on GitHub

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)}]}
where the SessionQuery is the huge all-encompassing query that I use for something else on the screen, but does have the two fields that Login needs?


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.

Jakub Holý (HolyJak)10:03:25

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.

Jakub Holý (HolyJak)11:03:28

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

Jakub Holý (HolyJak)11:03:27

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


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?