<< I much rather have unidirectional data flow and have ui/dom events only dispatch messages back. So view model data -> ui -> messages >>
Ah! Enlightenment. Thank you. On Wed, Mar 4, 2015 at 3:51 PM, Daniel Kersten <dkers...@gmail.com> wrote: > 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. > -- 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.
