Fork me on GitHub
#om
<
2015-08-19
>
acron13:08:19

Hi, I'm having trouble with ref cursors. would anyone be willing to take a look at this brief example? https://www.refheap.com/108488

acron13:08:47

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

jackjames14:08:25

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

troyclevenger14:08:00

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

acron14:08:42

gonna try this now simple_smile

acron14:08:26

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

acron14:08:40

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

troyclevenger14:08:18

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

troyclevenger14:08:56

@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.

acron14:08:32

Okay, yeah, that makes sense

troyclevenger14:08:02

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

jackjames14:08:40

@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

troyclevenger14:08:22

@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.

acron14:08:26

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

troyclevenger14:08:56

Otherwise component parameters get ridiculous. 😞

jackjames14:08:33

@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

acron14:08:11

as you say, this example is contrived simple_smile

troyclevenger14:08:18

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

troyclevenger14:08:14

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.

acron14:08:20

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

jackjames15:08:02

@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: https://www.refheap.com/108497

acron15:08:17

jackjames: this looks really nice.

acron15:08:02

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?

acron15:08:12

previous*

jackjames15:08:08

@acron: true in both. not a problem.

jackjames15:08:37

@acron: (watch nothing happening in your console when clicking buttons: https://www.refheap.com/108497#L-45)

acron15:08:58

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

acron15:08:37

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

acron15:08:49

(does that make sense?)

troyclevenger15:08:37

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.

jackjames15:08:33

@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

jackjames15:08:03

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

acron15:08:47

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

acron15:08:04

it feels like some re-jigging is in order

troyclevenger16:08:56

@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.

jackjames16:08:18

@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: https://www.refheap.com/108500

troyclevenger16:08:08

@jackjames: All that makes sense. Thanks!