A fromJS api (opposite of toJS)?

[antitoxic]

Hello and kudos for the new state-handling approach.

Having server-rendering and time-traveling in mind, is it not possible to make fromJS api that will read a plain object and create all necessary nested classes defined in the observable structure?

[AriaFallah]

Isn't that what observable does? It takes a plain object/array/value and will make every part of it observable.

[mattruby]

I think Anton is dealing with computed fields and such. So he'd want his
classes hydrated. Please correct me if I'm wrong.

On Thu, Jun 2, 2016 at 10:55 AM, Aria Fallah notifications@github.com
wrote:

Isn't that what observable
http://mobxjs.github.io/mobx/refguide/observable.html does? It takes a
plain object/array/value and will make every part of it observable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#297 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAIrchwY8pKTaCWw1D0pGnisizxrsUQyks5qHvzcgaJpZM4Issnj
.

-Matt Ruby-
mattruby@gmail.com

[antitoxic]

@mattruby exactly. As per mobx-reactive2015-demo my store consist of nested classes with @computed fields.

If we think of toJS as serialization of observable structure with nested classes, I want exactly the opposite. Does it makes sense?

[mattruby]

@antitoxic Yeah, it makes sense. But I don't think MobX is going to handle that out of the box. I've tried to match my data to the toJS output whenever I've needed that functionality. Then I just run the data through the same init code to create my MobX graph again.

[antitoxic]

Then I just run the data through the same init code to create my MobX graph again.

I don't quite get this. What do you mean by 'init code' ? Do you have an example I can try to learn from?

[mattruby]

@antitoxic Here's a simple example of what I'm talking about: https://jsfiddle.net/yxvz4wk6/

[antitoxic]

@mattruby I understand. So a factory pattern.

However I would argue that this can be automatic because 99% if not 100% of use-cases the passed in object keys match properties of the observable. Why do you need a constructor and all the code? Your example proves this actually.

I liked mobx because it removed a lot of boilerplate for me. This seems like a good opportunity for "mobx to the rescue" .

Would a utility function that walks js object recursively and fills an observable be a good fit for mobx?

mobx.fromJS(jsObject, targetObservableStructure);

When a key match is found mobx checks if its a user-defined class (or array of such) and creates recursively continues setting properties from the jsObject to the targetObservableStructure.

Am I missing something / being naive (completely possible :) )?

[mattruby]

@antitoxic Yeah, that example had very little need of all that work. In my experience, things get hairy when you have the cyclical references: parent > child with child > parent relationships. The cyclical nature of that can be rough to serialize and de-serialize in a standard way.

Regardless of that. I think your example would be possible. Not sure if it's good fit for the core. That would be on @mweststrate

What I'm still not getting is if you're pumping the data into MobXed objects once, why not just do it again?

[antitoxic]

parent > child with child > parent relationships

True, but how often do you have those?

if you're pumping the data into MobXed objects once, why not just do it again?

I'm never pumping data like this. The user actions change the data, push new objects or remove others - these are all small patches. The only time I'm creating a mobx observable from a large js object is on initializing. There might be another scenario but I can't think of it.

[mweststrate]

Thanks for the suggestions and questions so far! Providing a standardized mechanism for fromJS and more advanced toJS patterns is definitely on my agenda and I am thinking about for already a while now. fromJS is harder as you need to be able to somehow influence / define the mapping, but I will try to get an api proposal up somewhere this weekend or next week.

[prashaantt]

+1. Here's something I found dealing with a similar but more generic problem: https://github.com/JohnWhiteTB/TypedJSON.

[jaysoo]

@mweststrate Very interested in hearing your proposal for fromJS implementation. We are working on server-side rendering right now, and are looking into a mechanism for serializing and deserializing state.

Another thing we need is a way to serialize a graph into JSON (string), and back again. Currently, JSON.stringifywon't work because of circular data.

Basically something like:

const identity = compose(toJS, toJSONGraph, toJSON, fromJSON, fromJSONGraph, fromJS)

const state = new AppState(/* ... */)

assert.deepEqual(state, identity(state), 'must be isomorphic'))

Any thoughts on the server-side rendering use case?

[mweststrate]

Closing this issue as fromJS is part of the roadmap (see #323) and refers to the things described in this story. But it ain't forgotten ;)