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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
