5 ms·
Hi there -- thanks for your work on Om, it's helped to bend my mind and think about different ways of building apps. I agree completely that the easy snapshot
by haberman 13y ago
Hi there -- thanks for your work on Om, it's helped to bend my mind and think about different ways of building apps. I agree completely that the easy snapshot ability is very cool and it wasn't my intention to minimize it.
The main reason I dug into this so deep is because after reading your article I had a nagging feeling that using anything other than React or immutable data structures was an architectural dead end. But I'm not so worried about that now; I think that any framework that aggressively batches DOM updates will probably be ok performance-wise, and I think that mutable data structures can perform well.
Also I think that some features are easier to provide with mutable structures, such as automatic two-way data binding a la Angular. How do you propagate DOM changes to your models? Manual event handlers or do you have something more automatic?
I definitely think that immutable data structures are worth consideration for their snapshotting ability though.
- swannodette 13y agoI personally don't see much value in automatic two way binding. It's a little bit of convenience that's really easy to build over React/Om if that's your cup of tea, http://facebook.github.io/react/docs/two-way-binding-helpers.html http://facebook.github.io/react/docs/two-way-binding-helpers.... Immutability doesn't present any challenges here.
- haberman 13y agoReactLink (which you linked to) calls setState() on the React component state when the DOM changes -- wouldn't this violate the assumptions of your shouldComponentUpdate() implementation?
- swannodette 13y agoWe don't use setState, but we have om.core/set-state! which does pretty much the same thing - an OmLink would not be very hard to do.