Hi David, > Not to detract from the Cloact approach but the problem here is having to do > the merge by hand and thus that logic for snapshotting and reinstating will > need to be replicated from application to application. It could be abstracted > away, but this is the type of additional complexity that I am interested in > avoiding.
It's been my experience that this kind of snapshotting is generally trivial (order of a few lines), quite simple, and usually something I'd want to be doing manually anyway since usually not _all_ state is or should be subject to undo and/or tracking (non user-induced state pushed from the server, for example). I'd definitely agree with you if we were talking about a multi-threaded environment, btw. There the increased difficulty of reliable snapshotting might make the always-single-state-container approach a more reasonable default. As you say, it's a matter of trade-offs: I wouldn't suggest that one approach is objectively superior to the other. Om's beautifully implemented, but (completely subjective comment here) - I found the approach was introducing a relatively significant amount of conceptual overhead. It's at an early stage, absolutely - so that criticism may not be relevant long term. Anyway, I do find the flexibility of choosing how+where state is stored to be a plus in practice, especially during prototyping stages and when migrating from an existing code base. > The other option in Cloact is to use a single atom approach, but then you > have mixed universe of snapshottable components and ones which aren't. I'm quite happy with having that flexibility since it allows me to make trade-offs as/when I need them. > Also a model that emphasizes local state like this, which React suffers from > as well, can not leverage as many rendering optimizations in the future as Om. I'm curious what you have in mind here and why you're describing it as "local" state. If I've understood React's diff algo correctly, it seems so long as we're handling our dirty/not-dirty marking accurately, we're subject to "all" optimisations, always. Since the atoms are immutable and their comparisons done as identity checks, I'm not seeing how much room there'd be for improvement driven by ClojureScript's side? Again, not at all criticising - think Om's wonderful and would love to have any misunderstandings corrected. Have an awesome day, cheers! :-) - Peter -- 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.
