Fork me on GitHub

Hi, I'm having trouble with ref cursors. would anyone be willing to take a look at this brief example?


The selected-item-title updates only once. Subsequent updates to app-state make no difference.


@acron: think you need to deref "item" in the handler on L39


@acron: Have you tried just (swap! app-state assoc :selected-item item) for L39?


gonna try this now simple_smile


jackjames: did the trick...thanks. simple when you know how


troyclevenger: I always try to opt for transact!/update! rather than swap!/reset! - my understanding is that om requires this?


@acron: I've had it work with swap!. I usually use that for things when I don't have access to the cursors.


@acron: Like when loading data from the server. I use transact!/update! when I'm deeper in the hierarchy and need to make edits to things local to the om component. If that makes sense.


Okay, yeah, that makes sense


I'm only on my first real om application I still have stuff to learn. simple_smile


@acron: note that ref cursors are not going to be a thing in om-next. (in the meantime) they add complexity, so it's wise to use them sparingly. i guess this may be just a contrived example, but if your app looks like this, doesn't look like a scenario where ref cursors add value


@jackjames: In my app we've developed "stores" of information. I use ref-cursors for those so that components don't need to keep passing down data to children. This seemed like a perfect fit for ref-cursors.


jackjames: my understanding is that of troy, and as a relative newcomer to Om, ref cursors are advertised as a 'solution' to this problem


Otherwise component parameters get ridiculous. 😞


@troyclevenger: you can make a case for their use in various scenarios (though not so much once they no longer exist in om-next). just pointing out that @acron's refheap is not one of those scenarios


as you say, this example is contrived simple_smile


@jackjames: Right, @acron could just use the cursor passed in to get that value.


I'm hoping the path from om->om-next won't be too bad. Since I'm using this for real work I've got deadlines. Hehe.


Yeah, I'm pretty comitted to Om for this project


@acron @troyclevenger given that cursors (and ref cursors) are not long for this world, i think it's reasonable to consider getting out of the cursor business in the om apps you're building right now:


jackjames: this looks really nice.


jackjames: would it be true that the whole root component is rendered when a selected item changes? would that also be true in my pervious example?




@acron: true in both. not a problem.


@acron: (watch nothing happening in your console when clicking buttons:


cheers jack, appreciate you taking the time to demo this simple_smile


is is possible to control rendering at a sub-om/root level?


(does that make sense?)


So, I think I see what's going on with the control-event! methods, but what about the ref-cursor scenario. Where I want to have a nested component track data at a different level in the app-state.


@troyclevenger: my refheap is not a solution to that problem. but you can still use ref-cursors (for now). i rarely do, however, because i rarely encounter a situation where i need/want to pay the additional complexity cost. i try to keep my component tree fairly shallow, which keeps props-passing boilerplate reasonable. and then use component local state when appropriate to prevent e.g. form input values from having to make a round trip all the way back down to a (again, hopefully not too) deeply nested component


not clear yet what the potential strategies will be w/ om-next. def won't be ref cursors though


this sounds like good advice. i'm going to re-think my approach


it feels like some re-jigging is in order


@jackjames: Right. If you don't mind, let me ask you what you'd do. I have several deep tree structures like directories that I have to render. One of the things that gets cumbersome is that I am passing down {selected-item, select-item, expanded-nodes, etc} to my child nodes. Is this really the only way to go about it, or can you see a better way. I thought of channels, but wasn't sure it would save me that much.


@troyclevenger: ref cursors were designed as a mechanism to avoid passing props through components that don't care about them. so it's reasonable to employ them for that purpose. it's not free though. i typically just go ahead and pass stuff through. doesn't bother me. i would not likely consider using channels for this. i suppose you could consider strategies for minimizing the props that need to be passed down:


@jackjames: All that makes sense. Thanks!