regarding the comment I made about Hoplon, it seems that if you want to listen to different parts of the tree then in effect you are saying that when one part of the tree changes that you would like to project that part of the tree onto another part of the tree, which is something hoplon does. Maybe an atom to watch the Om tree could do the same
On Thursday, April 10, 2014 11:02:26 AM UTC+2, Dimitris Stefanidis wrote: > I was thinking about the same too and was trying to find a way to apply this > in om since this problem appears too often. > > > > It would be nice if I could have a products vector in my state and a selected > products vector. The products list component would get both products and > selected products cursors and would add any selected items in the selected > products cursor. Other components could get the selected products cursor and > display summaries detailed lists e.t.c. > > > > This way components do not have to know anything about the structure of the > application state. Of course there might be other caveats in this approach > that are probably missing me. > > > > On Thursday, April 10, 2014 11:49:03 AM UTC+3, Jack Schaedler wrote: > > > Does it make any sense to allow components to reference multiple cursors? > > Instead of specifying a single path into the application state, you would > > specify a collection of paths within the state atom, all of which would > > trigger re-renders and allow for transact! and update!? I often find myself > > pulling component cursor paths 'up' the tree in order to ensure that the > > cursor is broad enough to capture all of the state changes that might cause > > a re-render. > > > > > > > > > > > > That being said, I still have the feeling that in the majority of cases, > > the confined scope of the cursor guides me towards a more sensible layout > > of the application state. > > > > > > > > > > > > > > > > > > On Thursday, April 10, 2014 4:12:31 AM UTC+2, David Nolen wrote: > > > > > > > Yes it's a problem that you encounter in React if you try to do things in > > > a functional manner. It's not really a "limitation" of React or Om. But > > > at least in the case of Om I consider it a deficiency great enough to > > > build direct support so that users aren't hampered by it or forced to > > > come up with their own ad-hoc solutions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 9, 2014 at 10:05 PM, Brendan Stromberger > > > <[email protected]> wrote: > > > > > > > > > > > > > > I've encountered this issue in vanilla React (js), and couldn't figure > > > out any other way than munging my data together such that I could pass it > > > down in the way OP describes. I guess my question is, is this limitation > > > inherent in React or in the Om abstraction? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday, April 9, 2014 3:52:05 AM UTC-7, David Nolen wrote: > > > > > > > > > > > > > > > You're not missing anything. This is a fundamental issue in Om right > > > > now and I've been designing and working on a fix. Basically in the very > > > > near future a component will be able to access something in the > > > > application state without needing a parent component to pass it in from > > > > above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The idea is that a component will be able to get its data directly from > > > > the app state with something like (om/get-shared owner [:app-state > > > > :foo]). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still working out the details, but this work is happening in the > > > > `ind-components` branch. When it's finished there'll be an accompanying > > > > nested tab view example - one of the cases that suffers the most under > > > > the current system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 9, 2014 at 6:33 AM, Daniel Kersten <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to figure out the best way of structuring complex > > > > applications in Om and I've hit a bit of a brick wall that I'm hoping > > > > someone can help me with. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I like the concept of cursors - narrow down the application state to > > > > what the individual components actually need and allow them to read and > > > > modify only that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem I'm having is that I don't know how to structure my state > > > > so that the correct components have access to everything they need. Its > > > > easy if each component only requires a strict subset of its parent, > > > > which is often the case, but not always. I've hit a scenario where a > > > > component needs access to two very different branches of the app state > > > > and I'm not sure how to pass it to the component that needs it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a (contrived) example, imagine you had an app for displaying orders > > > > in an online store and the application state is something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (def app-state (atom {:items [{:type "book" :price 123} {:type "cd" > > > > :price 200}] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > :orders [{:date xxx :type "book" :count 3} {:date > > > > yyy :type "cd" :count 1}] > > > > > > > > > > > > > > > :filter "book"})) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can imagine that in a real application the :items and :orders > > > > branches may be much deeper. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lets say I now have two components, one displaying the items (so it is > > > > passed a cursor with path [:items]) and one displaying the orders (so > > > > it is passed a cursor with path [:orders]). What if I now only want to > > > > display items and orders where the type matches the filter? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a few options: > > > > > > > > > > > > > > > Restructure the app state in a way that gives each component access to > > > > what it needs. This is not ideal as it means that I'm modelling my > > > > state after how its being rendered rather than how its being processed > > > > and makes it very application specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can propagate the additional values down the component tree (eg using > > > > the :state parameter to build), but this means that every other > > > > component before the one that consumes it must now do additional work > > > > that it shouldn't need to know about (couples the parent components too > > > > tightly to the child one) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Similarly, passing it in opts is not ideal as it has the same issue as > > > > #2, with the added caveat that the component also won't rerender on > > > > change.I can store the value in component local state and update it > > > > through a core.async channel. This works well in the example above, > > > > where one or two simple values need to be communicated, but gets unruly > > > > when the application is more complex. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can pass the entire app state to each component (perhaps trough > > > > shared state) and use transformation functions (similar to what Sean > > > > Grove did in his recent slides) to transform the state into a local > > > > view for each component. This means each component gets to select > > > > exactly what it needs to access without worrying about what comes > > > > before or after it in the hierarchy, but then you lose the benefit of > > > > cursors and automatic re-rendering when something changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm sure I'm missing something! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any tips appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 [email protected]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To post to this group, send email to [email protected]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 [email protected]. > > > > > > > > > > > > > > To post to this group, send email to [email protected]. > > > > > > > > > > > > > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
