Kinda getting started with Reagent and doing a lot of (::foo @state) which as I understand it will rerun the function every time state changes, rather than every time ::foo changes. Is there like a straightforward "do this instead" or it's complicated and you have to architect your state into smaller bits? The solution probably involves cursors or reactions... Looking at https://github.com/reagent-project/reagent/blob/master/doc/ManagingState.md I should probably just make all the interesting pieces of my state atom a cursor, or just split up the state atom in smaller bits? Is there any advantage of doing the one or the other? The cursor one probably makes it easier to do atomic updates?

Can I just s/(:foo @state)/@(cursor state [:foo])/ or you need to define it at the top level?

@pepijndevos Yes, use cursors. Or alternatively, if this is in Re-frame, use subscriptions. And don’t deref the cursor directly as part of creating it (in your regex example above you are doing both at the same time). You can create it in a let (local binding) and then you can deref inside of a form-2 component’s render function. Then you will have properly separated the creation of the cursor (should happen only once) from the reactive deref (should happen every time the cursor’s value changes).

e.g. something like

(defn my-component []
  (let [my-cursor (cursor state [:foo])]
    (fn []
      [:div @my-cursor])))

Huh.... the extra fn is just there to make sure the cursor is only evaluated once?

Read this: https://purelyfunctional.tv/guide/reagent/

It explains what form-1, form-2, and form-3 components are.

When you return a render function in reagent, (what I did) that’s a form-2 component. When you define a render function directly, that’s a form-1 component.

You can also do this as a form-1 component, but in that case you will need to def your cursor somewhere inside the namespace. If this is a single-use component that is definitely also possible. Regardless, you should still learn about form-2 components 🙂

ty

np! Good luck.

But so like uh... inside utility functions and event handlers and the like, you probably want to def the cursor I guess

No, you should never def anything inside a function. That is an antipattern. Defs should only be top-level. Use local bindings - i.e. let - if you need to access something by name after it’s been created. If you need to access it globally, then yes, by all means, def it inside the namespace.

Yea that's what I mean, def at the top level. If you let it inside an utility or event handler then it will be evaluated multiple times

Exactly. And the state will be erased every time, which you definitely don’t want.

Erased??? You mean the cursor keeps some cache I suppose?

If you re-def something, then whatever it was before will be erased.

You should only def something once ( unless you’re debugging at the REPL).

(sorry, I read your comment as “if you def something…” so my reply was to that)

Yea I'm basically wondering how bad @(cursor state [:foo]) is (adding a let doesn't change much in this case)

Yeah, if you calculate something in a let inside a function and then keep calling that function, you will probably be redoing that calculation.

I don’t understand what you’re on about now. Obviously adding a let by itself doesn’t change much if you don’t make a form-2 component, but the point of a form-2 component is that the outer function is run only once, in which case you will only create the cursor once.

The idea is to separate cursor creation from rendering.

So don’t deref in the let , do that in the render function that the component returns, i.e. what I did in my example. Otherwise, if your component isn’t meant to be reused at all, just def your cursor inside the namespace and deref it from a form-1 component.

Merging cursor creation and deref’ing is indeed bad if the point of the cursor is achieving better performance, which is pretty much always is. Why bother with cursors if you’re not looking to get better performance?

> I don’t understand what you’re on about now. Obviously adding a let by itself doesn’t change much if you don’t make a form-2 component, but the point of a form-2 component is that the outer function is run only once, in which case you will only create the cursor once. it sounds like @pepijndevos is asking what the cost of:

(defn my-comp
  (let [my-cursor @(cursor state [:foo])]
    [:div @my-cursor]))

it doesn't sound like they're confused how reagent cursors & form-2 components work on a fundamental level

obviously you're going to be reconstructing the cursor object every render here. the cost of that shouldn't be too high

it looks like, reading the source, that when you initially deref a cursor it creates a new reaction that does (get-in ratom path) and caches it on the ratom itself

https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.cljs#L275-L278

cached-reaction is quite a hairy function but it seems that in this case it sets a field on ratom that contains a cache of reactions that depend on it, keyed by the path given to the cursor

the way i'm interpreting it is that repeated calls to (cursor state [:foo]) will reuse the cached reaction instead of constructing a new one

There's :on-dispose - wouldn't it be called for the @(cursor ...) above?

Probably not, given that re-frame caches its subs in a similar way.

yeah since reagent detects usage of the same reaction across renders, I don't think it will dispose of the reaction

the old cursor object will get garbage collected, but that doesn't trigger disposal

Okay so conclusion is, it's best to use form-2+let or toplevel def, but in utility functions the overhead of creating a new cursor is reasonably small? Is there a good way to profile this kind of stuff? I can't say I've tried very hard but glancing at the Firefox profiler it was kind of opaque what was causing needless rendering.