Fork me on GitHub
#om
<
2017-05-18
>
rgm02:05:29

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?

rgm03:05:38

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

rgm03:05:23

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

rgm03:05:25

(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).

rgm03:05:18

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

rgm03:05:10

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.

rgm03:05:10

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?

rgm03:05:48

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

tony.kay03:05:22

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

tony.kay03:05:47

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

currentoor11:05:57

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

tony.kay16:05:00

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

currentoor16:05:25

@tony.kay that was the issue for me recently đŸ˜„

tony.kay16:05:14

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

tony.kay16:05:50

I was just thinking of the index lookup part facepalm