Hmmmm, maybe 'cursors' is the typical/standard means for addressing this?

@jsa-aerial yeah that’s not always true. You can have cursors and other sorts of reactions that derive from some subset of the single ratom state. These constructs can intelligent avoid re-notifying watchers, eg re-rendering, when the change doesn’t result in a difference derived value.

@mikerod I see - sort of - what are these 'intelligent constructs'? Another idea I had is to have ratoms in the main ratom to differentiate these things. Since changes to these 'sub' ratoms would not change the value of the containing ratom, that might be a workable solution.

@jsa-aerial There are other constructs beyond the ratom

those can derive from data based on a ratom and there are built-in checks they perform to ensure that what they depend on has indeed changed

like a rcursor will only depend on a value at a path in the ratom (or reactive thing it depends on)

and if the value at that path hasn’t changed, then the watchers (eg would be component renderers) of the cursor won’t be updated

In the case of ratom’s, if the value at the path is identical? watchers aren’t notified

identical? is the test most often used

Right - but do these (other than 'cursors') exist in reagent or some lib or are these typically hand rolled?

there are others

ns reagent.ratom defines several

for different sort of usage-scenarios

https://github.com/reagent-project/reagent/blob/master/doc/ManagingState.md docs on some

if you scroll towards bottom, you’ll see things like track! and reaction

Not that that makes a difference in this context...

I thought I read all of that but I may have stopped after cursors. :thinking_face:

I’m a fan of re-frame nowadays. The default there is for a single ratom to hold all of the app state

re-frame uses reactions to based derived views on the single app state data. Re-renders are avoided due to this change detection built into the reactions

I see - was thinking of looking into re-frame as a mid-term thing, but maybe need to bring that forward. All that reaction stuff (with the numerous protocols) is rather low level and complicated. Nice to build something with - apparently like re-frame....

I like reagent and created a large-ish app before with it alone

over time I started buying into the re-frame ideas more and more and I switched to it for future app’s and also uplifted the larger reagent one I had. One main reason is I like the better prescribed structure and “life cycle” of re-frame

reagent alone, to me at least, is more of a “do it yourself”.I still think you’ll wind up creating some sort of “framework/architecture” around the reagent constructs anyways - so it just comes down to if you like re-frames model or not

On that note, here you go https://github.com/Day8/re-frame/blob/master/docs/FAQs/DoINeedReFrame.md

@mikerod Thanks for this - appreciated!

@jsa-aerial I totally agree with what @mikerod says above. For me, I just follow a fairly simple and rigid practice of “subscribing” to the data I need in the main ratom by creating cursors in a let-block to the specific paths I need for any given component. this keeps its rerender minimal and has the side benefit of making it easy to see what data a component depends upon. I think re-frame does this or something similar with its subscription mechanism.

Thanks for the insight everyone! I think what I missed was the rerendering. We might explore cursors to make it more specific, so non-reframe-subscribed field components can still “work” when you type text.