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.


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 but perhaps not so helpful here...

👍 1

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?