4 ms·

I really like the Om/Omniscient model of using immutable data to represent application state - deciding whether or not to rerender a component and all of its su

by BFay 11y ago

I really like the Om/Omniscient model of using immutable data to represent application state - deciding whether or not to rerender a component and all of its subcomponents only requires comparing a hash. However, for the app I'm working on, I want most the single source of truth for most application state to be on the server. I'm passing data from server to client in JSON. Has anybody come up with a good way to serialize/deserialize immutable objects? I might try out transit-js, but I'm wondering if anybody has already gotten this working?

TheAceOfHearts 11y ago
I'm using Fluxible [0], with immutable.js [1], and I just create my stores using createImmutableStore from fluxible-immutable-utils [2]. Since you're keeping the state for each store in context._state it'll just call context._state.toJS() when you're dehydrating, and Immutable.fromJS(payload) when rehydrating. [0] http://fluxible.io/ http://fluxible.io/ [1] http://facebook.github.io/immutable-js/ http://facebook.github.io/immutable-js/ [2] https://github.com/yahoo/fluxible-immutable-utils/ https://github.com/yahoo/fluxible-immutable-utils/
- BFay 11y ago
  Thanks, fluxible looks like it might be the best isomorphic solution available right now, and the fromJS() and toJS() functions are what I would need. I guess I was initially hoping to use immutable data for the performance benefit; being able to implement a fast shouldComponentUpdate() with a simple equality check. But I wonder how toJS() and fromJS() performance-wise... if they have to create new objects by deeply copying the objects, maybe that would be just as bad as doing no shouldComponentUpdate optimization. I guess I'll just stick to the "premature optimization is the root of all evil" concept, and try to get something working with carefully mutable data first.
  - TheAceOfHearts 11y ago
    Oh, no no. That toJS() and fromJS() only happens on the initial load, it's pretty fast. Using immutable.js you can get way better performance and you don't have to worry about data ever changing on you unexpectedly.

by BFay 11y ago

TheAceOfHearts 11y ago

I'm using Fluxible [0], with immutable.js [1], and I just create my stores using createImmutableStore from fluxible-immutable-utils [2]. Since you're keeping the state for each store in context._state it'll just call context._state.toJS() when you're dehydrating, and Immutable.fromJS(payload) when rehydrating. [0] http://fluxible.io/ http://fluxible.io/ [1] http://facebook.github.io/immutable-js/ http://facebook.github.io/immutable-js/ [2] https://github.com/yahoo/fluxible-immutable-utils/ https://github.com/yahoo/fluxible-immutable-utils/

BFay 11y ago
Thanks, fluxible looks like it might be the best isomorphic solution available right now, and the fromJS() and toJS() functions are what I would need. I guess I was initially hoping to use immutable data for the performance benefit; being able to implement a fast shouldComponentUpdate() with a simple equality check. But I wonder how toJS() and fromJS() performance-wise... if they have to create new objects by deeply copying the objects, maybe that would be just as bad as doing no shouldComponentUpdate optimization. I guess I'll just stick to the "premature optimization is the root of all evil" concept, and try to get something working with carefully mutable data first.
- TheAceOfHearts 11y ago
  Oh, no no. That toJS() and fromJS() only happens on the initial load, it's pretty fast. Using immutable.js you can get way better performance and you don't have to worry about data ever changing on you unexpectedly.