I understand regarding nested components, makes lots of sense and r/wrap should help, but I've yet to use it personally since I'm just literally starting to write my first Reagent app....
I think the missing part of the picture you're painting is that components can have specialized instances, so a reusable input box may take first name, last name, or email or etc, and sending the whole form-data sub-tree for input to the input component (i.e. first name, last name, email, all that) means that typing the first name into the input box will cause all other instances of the input box (ones holding last name, email, etc) to update. So I tend to send down only the slice of the atom that is required by the given instance. I'll present a more comprehensive architecture including State Manager as a re-usable abstraction (!) Please keep discussing to whatever depth necessary, I'm sure my thinking on this is still lacking. p.s. the 1st meetup in SF will be announced tomorrow so a bunch of us can talk live about this stuff On Wed, Mar 4, 2015 at 4:48 PM, Daniel Kersten <dkers...@gmail.com> wrote: > I do find cursors fantastic for reusable isolated components. For example > if I have a widget that edits some data, I find it useful to give that > widget a cursor that it may modify, but it needs to be managed by the > parent so that what happens to the data is transparent to the widget. The > parent might then actually dispatch messages and the cursor is only really > for one layer on the boundaries. Reagents (r/wrap data func ...) seems > ideal for this. > > I hope that makes sense - typing on a phone right now. I'd be happy to > discuss more tomorrow when I have a real keyboard. > > > On Thu, 5 Mar 2015 00:26 Marc Fawzi <marc.fa...@gmail.com> wrote: > >> 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. >> > -- > 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.
