Sounds like you may want a reactive programming model like Hoplon instead if you want to do this:
http://hoplon.io/ 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.
