Clojurians Log v2

Cursors are lightweight objects and it is fine to create them when you need to. The question is more about data scoping: what information you want to give to your children, do they need the full state or not. Sometimes by creating the cursor in a parent, you make your children more flexible about the data they can receive and so less dependant on the global state. But I'd say optimization is really not the main question here, until there's a real performance issue. I can't answer for how many is too many it's quite well optimized but depends of the structure of the state and of your components. But note that it will be faster to have a cursor value check than rendering the component that is watching the cursor, so it's usually a good idea to use them a lot.

this is for a multiplayer card game with fairly complex game state, so we're building something like 60 cursors to look at various aspects of the state and then passing those as necessary to the child components

60 is totally fine

that's great news

Also if you have a complex state and want to pre-optimize a bit you could chain your cursors instead of defining all of them from the ratom.

(let [board-c (r/cursor gstate [:board])
      first-slot-c (r/cursor board-c [:slots 0])]

woah! i didn't realize you could chain cursors, that's really sick

that will be really helpful, thank you

I've just remembered an issue relating to that tho. If you update the ratom (directly or with a cursor, doesn't matter), the deref of the level 2+ cursors will give the cached value until the next render (or a manual call to r/flush). In my example:

@first-slot-c ; => 41
(swap! first-slot-c inc) ; => 42 (the right value is returned)
@first-slot-c ; => 41, still the same as before for now

(r/flush) ; or rerender of the components that is usually done the frame after the swap! is called
@first-slot-c ; => 42, now is the updated value

good to know