Clojurians Log v2

so I'm slowly slowly figuring out om.next architectural patterns in anger. Would it be fair to call complex (let [...]) manipulations within my components a code smell, and that these will somehow get rolled up into the reconciler's read functions?

eg.:

let's say I have a list component showing a subset of some big items/by-id table

the subset might have repeats, eg. [[items/by-id 1] [items/by-id 1] ...]

(I'm modelling something where there might be different quantities of the same item; it models uses of a building detail and they may be in different locations but still part of the "bag" of details).

and let's say I'd like to just have a unique-ified list available in the same component as a summary.

I can do this at the component in a let based on the props, but I have this feeling that this is supposed to be shoved into the reconciler/read function.

and let's assume I'm not totally off base on that: I'm having trouble finding good examples of how that sort of read function might get written, where I stuff derived properties into the {:value {:whatever}} ... I guess maybe as a final transform on what came back from the app state read?

eg. {:value (my-transform-to-add-derived-values {:values :from :query-driven :state :read})}?

Has anyone else noticed a problem with using a root-level property keyword in a follow-on read not triggering a root re-render?

seems to work when I use a kw from a root-level join

@tony.kay is the data being queried for changed by the mutation?

@currentoor Ah, right. I bet that is it.

@tony.kay that was the issue for me recently 😄

I just spaced that the re-query gets focused by the follow-on read…I was assuming the whole query was going to run.

I was just thinking of the index lookup part 🤦