Writing to cursors from within components (and generally changing app state from within a component) is not a good pattern. You want to have clearly defined places where state mutation can happen, and in the normal case you put those in event handlers (sitting outside the component but being passed the cursor from the component which can be specified during event setup)
So this is all about architecture choices, not cursors vs no cursors. On Wed, Mar 4, 2015 at 2:47 PM, Erik Price <e...@zensight.co> wrote: > Cool, thanks for following up, Mike. I agree with pretty much everything > you describe, especially writing to cursors from within a Reagent > component. We're using an approach that I'm really happy with (and may blog > about at some point), which mitigates the problems you mention even though > we are using cursors. Cheers! > > e > > On Wed, Mar 4, 2015 at 4:15 PM, Mike Thompson <m.l.thompson...@gmail.com> > wrote: > >> On Saturday, February 28, 2015 at 1:44:52 AM UTC+11, Erik Price wrote: >> > On Thu, Feb 26, 2015 at 7:55 PM, Mike Thompson <m.l.tho...@gmail.com> >> wrote: >> > >> > The key thing for me is: JUST. DON'T. USE. CURSORS. There I said it. >> They appear convenient, I know. They are a way of achieving reference >> transparency, I know. But I think they are a “local optimum”. Their use >> seems to get in the way of a more important data flow paradigm and they >> seem to encourage "control" into all the wrong places (components). At >> least that's my experience (I did try to love them, really I did :-)). >> > >> > >> > >> > I'm fairly new to Reagent, so as far as I can tell, cursors look great. >> But it sounds like you've run into situations in which they aren't helpful. >> Can you elaborate? >> >> >> Cursors are convenient. You'll get going pretty quickly with them, for >> sure. >> >> But if your app gets a bit bigger you might find some code smell starting >> to appear. >> >> - their use can sometimes distort the way you structure you data. >> Cursors want you to layout data hierarchically (which often fine) but one >> day you'll find yourself twisting your data structure so as to facilitate >> Cursor use. >> >> - Cursors are simple extractors (which abstract away the path). But they >> are not about "Derived Data" or "Materialised Views". They don't deliver to >> your view a modified version of the data. Yes, you can modify the data in >> your view, but that means the view is doing too much. Take a view that >> needs to show the top 20 items in a vector, when sorted by attribute Y. >> Now imagine that you have two views on the same data each with different >> sort criteria. The underlying data can't be sorted two ways at once. So >> the view will have to start doing the sorting. >> >> - the "write back" feature of Cursors is something I really don't like. >> As an app gets bigger, the control logic around updates gets more >> complicated. Using writable Cursors is a slippery slope towards more >> control logic getting put in the views. >> >> Overall, I find that Cursor use encourages you to make views do too much, >> know too much, which tends to be a problem as apps get bigger. >> >> >> -- >> Mike >> >> >> . make your use of Cursors easy, rather than modeling the right way. >> >> they can sometimes encourage you to structure your data in a tree-like >> way ... even though certain way. >> - The main problem I have with Cursors is that they are writable. >> I've found that they encourage control logic into views. I prefer my >> views to be very passive. >> >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojurescript+unsubscr...@googlegroups.com. >> To post to this group, send email to clojurescript@googlegroups.com. >> Visit this group at http://groups.google.com/group/clojurescript. >> > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
