[ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
0.6.2 seems to work great! I did have one issue with the tx-listen mechanism. I have a bunch of root components, and had to move the registration of the tx-listen function to the first call to om/root. Otherwise, the tx-listen function would not get called. I noticed that there was a bug-fix commit related to multi-root apps using tx-listen, so this is probably just a case of me misusing the feature in pre 0.6.1 versions. See the commit in the Goya repo here: https://github.com/jackschaedler/goya/commit/21e26869e2ceeb44a5fc8e132f4a72e697ca0fc3 On Thursday, April 24, 2014 7:03:37 PM UTC+2, 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 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.
Re: [ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
Thanks for the report! This seems like a bug, I went ahead and filed an issue for it. David On Mon, Apr 28, 2014 at 3:40 PM, Jack Schaedler jwschaed...@gmail.comwrote: 0.6.2 seems to work great! I did have one issue with the tx-listen mechanism. I have a bunch of root components, and had to move the registration of the tx-listen function to the first call to om/root. Otherwise, the tx-listen function would not get called. I noticed that there was a bug-fix commit related to multi-root apps using tx-listen, so this is probably just a case of me misusing the feature in pre 0.6.1 versions. See the commit in the Goya repo here: https://github.com/jackschaedler/goya/commit/21e26869e2ceeb44a5fc8e132f4a72e697ca0fc3 On Thursday, April 24, 2014 7:03:37 PM UTC+2, 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 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.
Re: [ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
No problem. If you'd like me to test any changes, just let me know! On Monday, April 28, 2014 9:46:38 PM UTC+2, David Nolen wrote: Thanks for the report! This seems like a bug, I went ahead and filed an issue for it. David On Mon, Apr 28, 2014 at 3:40 PM, Jack Schaedler jwsch...@gmail.com wrote: 0.6.2 seems to work great! I did have one issue with the tx-listen mechanism. I have a bunch of root components, and had to move the registration of the tx-listen function to the first call to om/root. Otherwise, the tx-listen function would not get called. I noticed that there was a bug-fix commit related to multi-root apps using tx-listen, so this is probably just a case of me misusing the feature in pre 0.6.1 versions. See the commit in the Goya repo here: https://github.com/jackschaedler/goya/commit/21e26869e2ceeb44a5fc8e132f4a72e697ca0fc3 On Thursday, April 24, 2014 7:03:37 PM UTC+2, 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 clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@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.
[ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components
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 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.
