This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-19
Channels
- # admin-announcements (14)
- # architecture (1)
- # beginners (21)
- # boot (301)
- # clojure (93)
- # clojure-brasil (56)
- # clojure-india (4)
- # clojure-italy (11)
- # clojure-japan (25)
- # clojure-russia (16)
- # clojure-sg (1)
- # clojure-uk (5)
- # clojurescript (64)
- # clojurex (4)
- # clojutre (7)
- # cursive (18)
- # datascript (35)
- # datomic (212)
- # editors (27)
- # emacs (38)
- # events (9)
- # funcool (21)
- # hoplon (105)
- # jobs (2)
- # ldnclj (41)
- # ldnproclodo (4)
- # liberator (89)
- # luminus (5)
- # off-topic (32)
- # om (39)
- # onyx (1)
- # re-frame (9)
- # reactive (1)
- # reagent (34)
- # testing (42)
- # yada (4)
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
The selected-item-title updates only once. Subsequent updates to app-state make no difference.
@acron: Have you tried just (swap! app-state assoc :selected-item item) for L39?
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.
I'm only on my first real om application tho..so I still have stuff to learn.
@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
@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.
@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
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: (watch nothing happening in your console when clicking buttons: https://www.refheap.com/108497#L-45)
Yes, thanks.
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
@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: https://www.refheap.com/108500
@jackjames: All that makes sense. Thanks!