Cursors are intended to be a simple abstraction over data so I'm not sure I follow wrt ORM etc.
Om doesn't magically help with the rendering of large data sets, but I do think React/Om make it more pleasant to implement. On Thursday, April 24, 2014, Alan Moore <[email protected]> wrote: > To what extent are the issues you are addressing with Om and state/cursors > related to ORM-like problems? In a previous post: > > https://groups.google.com/forum/#!topic/clojurescript/88u7kcomnUA > > Here you mentioned that in Om you have a "database-like system + time > model". That made me think about the nasty ORM issues with databases and > how cursors could be thought of as falling into the same problem set. Maybe > there is something that can be learned (avoided?!) in Om. The component <-> > app state mapping(s) looks to be a fairly difficult problem. > > You probably already have this figured out so I'm interested to see your > solution. I'm especially interested to see how your solution will work with > a large state/DOM model and being able to support "progressive reveal". > > In our domain we have a very large data set that if fully rendered in the > DOM would consume too much time/space. We have tried to solve this problem > by only rendering those portions of the state into the DOM that are visible > to the user so as to avoid doing work that won't ever be needed. We provide > a means for the user to navigate into the data set and render only as much > as is necessary but our solution is clunky... > > It would be nice if Om is able to help us solve that problem. While we > aren't using it yet, I have been experimenting with Om and am stumbling > into the same state/data management questions as other have. In particular, > there is the notion of application data (e.g. user profile) that represents > the underlying data model for the domain (often stored on the server w/ > portions cached on the client) and then there is the > non-durable/temporary/non-shared client state that reflects the user's > interaction and component view of that application data (e.g. the user has > partially edited their profile's phone number.) > > Maybe Om already does all that and I just don't "get it"... TBD. > > BTW - thank you for all your hard work on Om. > > Alan > > On Thursday, April 24, 2014 10:03:37 AM UTC-7, David Nolen wrote: >> >> Om 0.6.1 significantly changes how component local state works - we now >> rely on React's forceUpdate to update components that use local state. This >> is a significant change so I would like people test this out on their >> existing code bases as soon as possible. >> >> The immediate benefit is that components now use `=` for the >> shouldComponentUpdate logic instead of `identical?`. This means >> considerably more flexibility with regards to what a component may receive >> without taking a performance hit with respect to rendering. Even more >> importantly it's a big step towards independently addressable components. >> >> What are independently addressable components? Currently many people >> struggle with the fact that parent components must take all the data >> associated with their children. This often results in a tight coupling that >> is not ideal for real applications. The next few releases of Om will be >> focused on providing a sensible solution to this issue without backing away >> from the existing efficient time travel capabilities. >> >> Feedback welcome! >> >> http://github.com/swannodette/om >> >> David >> > -- > 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]<javascript:_e(%7B%7D,'cvml','clojurescript%[email protected]');> > . > To post to this group, send email to > [email protected]<javascript:_e(%7B%7D,'cvml','[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.
