On Mon, Dec 23, 2013 at 5:10 PM, Conrad Barski <drc...@gmail.com> wrote:
> I should add I found Om very easy to work with (even in the pre-alpha > state) and liked the major design opinions. The cursor + single state atom > approach feels like an improvement over the React.js approach of > emphasizing separate state storage for each component. > I'm actually going to pursue optional separate state storage per component. This is useful if you want the incoming data to remain true to the real "model" and you like to put transient app specific state information elsewhere. This precisely why people use Model object's in MVCs, they allow you to encapsulate both the properties that represent the real data and side or transient app specific information. But people can chose to keep putting transient state information into the app state atom - it does allow you to capture transient states - this might turn out to be more useful than I can see right now particularly in the case of undo/redo operations? > The only (rather small) drawback I encountered to this design is that > sometimes the info in the cursor variable is an out-of-date version when I > needed to access it, which is easily resolved by making sure to access the > state only from within the "update!" function in those cases. (I haven't > fully wrapped my head around the behavior of the cursor yet, so this > confusion might disappear once I get more familiar with it.) This is a wart that I'm considering how to remedy. In my experience there are two big sources of this so far - go loops that you set up when your application mounts, and improper communication of change in the face of operations that move children nodes between one app state and the next (insertion, deletion, prepend, etc). If you don't handle this then you'll have items with stale paths. I think both cases are should be straightforward to address from Om such that users won't find it a common occurrence. Feedback welcome on any and all of this. 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.
