btw Daniel, If you care to discuss more deeply, what we do is use fine-grained cursors so the two-way cycles are avoided (since each cursor updates only the data for the given component *instance* and not for any other component or any other instance)
But I like centralizing state changes into a state manager and your idea of event handlers emitting state change events is very useful to make that work. Thank you again for your input. On Wed, Mar 4, 2015 at 3:57 PM, Marc Fawzi <marc.fa...@gmail.com> wrote: > << > 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.
