Hot State Reloading + MobX?

[aleclarson]

Explained in this article.

@mweststrate Could HSR be integrated into MobX? Curious about your thoughts on this.

[mweststrate]

Sounds like it could be integrated with anything that supports serializing the state? Whether that works for a MobX question can not be answered generically; some MobX encode their entire state in a single state, some don't. An example where it is done with HMR can be found here: https://github.com/mobxjs/mobx-reactive2015-demo

I am by the way working on a standardized state container which could easily support this, although that is still experimental and not finished (https://github.com/mweststrate/mobx-state-tree)

[KatSick]

@mweststrate i'm pretty interested in your solution with opinionated state tree, how can i help you with it ?

[mweststrate]

@ochervak at this point any feedback on the api is very useful, a good starting point is https://github.com/mweststrate/mobx-state-tree/blob/master/src/inode.ts and the static methods here https://github.com/mweststrate/mobx-state-tree/blob/master/src/node.ts#L189.

Probably it is a bit too vague still atm, but the idea is that

1. your state is always a tree
2. for each 'node' in your state tree (objects, arrays, maps, complex objects) you can obtain a Node object, which exposes all the methods from the inode file
3. objects are uniquely contained, so nodes can now their path.
4. within the tree, you can resolve identifiers (relatively, see the exapmle in the readme)
5. subscribe at any point in the tree, from which you can get the events (relatively from the point where you subsribed)
6. for each node, a snapshot is maintained, this is an immutable object (well, should not be mutated), which is structurally shared (as snapshots are part of the snapshot of the parent node in the tree etc). This can be used for time travelling, serialization etc.
7. on each node, you can start listening to json patchs, which can be used to easily create distributed state trees or for trim travelling again (e.g. a snapshot + patches form together the the current snapshot)

I'm currently writing the handler for plain objects, after that arrays, maps and complex objects should be added with a similar pattern

[zalmoxisus]

@aleclarson, that approach in the article isn't suitable for most of cases, even though it's simple and would help to avoid side effects.

Let's say we have that counter example. Increment the counter 2 times, then you changed the increment action (reducer):

increment (state, payload) {
-    return { count: ++state.count }
+    return { count: state.count + 10 }
}

The HSR refreshes the webpage and gives you the previous state 2, but we should have 20 instead.

The reason why it works with Redux DevTools is that it recomputes the reducers, and actually we don't need that state HSR provides at all.

Mobx Remotedev could recompute the actions as well, the problem is only with nested changes, which zalmoxisus/mobx-remotedev#5 would handle.

[mweststrate]

Closing, as within the MobX package itself there won't be a generic solution.