I've been using Om (and therefore cursors) heavily for almost a year and am finding myself moving further and further away from cursor. The issue for me is absolutely the write-back - allowing your views to write to them encourages your code to do so and encourages a style where your ui/dom event handlers mutate data. I feel like this is an anti pattern that makes it difficult to properly manage your state as the application grows unless you are very disciplined. I much rather have unidirectional data flow and have ui/dom events only dispatch messages back. So view model data -> ui -> messages
The messages can then be handled to update the view model or whatever in a managed way. It's very similar to flux and similar architectures. Mainly this buys you purer (in the functional sense) code, easier automated tests, easier to understand/reason about flow of data and ultimately a simpler design. That's my opinion at least. On Wed, 4 Mar 2015 22:57 Marc Fawzi <marc.fa...@gmail.com> wrote: > 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. > -- 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.
