Mobx: Hot module reloading and ES6 class mobx stores

Created on 19 May 2016  ·  12Comments  ·  Source: mobxjs/mobx

Hi I was curious if you knew of any example where modifying a store would not reset the state within the running application while using React-HMR?

It's because instantiating an ES6 class store would create a new object and call its constructor reinitiating state afaik.

📖 documentation

Most helpful comment

https://gist.github.com/rej156/4524b59ea77a697fb62a39eada5b9bbe
Managed to get it working, I deserialized my es6 class stores using JSON.stringify 👍

All 12 comments

Saw that already but any suggestions as to how to deserialize and serialize with ES6 class stores?

There is no standard solution for that in MobX, but you might use
mobx-model for that, or some arbitrary (de)serialization package.
(Personally I gave a little bit upon HMR though, to often issues with
decorators not being picked up etc, not being able to use stateless
functional components etc, so for just HMR itself I wouldn't go through
this trouble)

Op do 19 mei 2016 om 13:33 schreef Eric John Juta <[email protected]

:

Saw that already but any suggestions as to how to deserialize and
serialize with ES6 class stores?


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
https://github.com/mobxjs/mobx/issues/254#issuecomment-220298796

Yeah surprisingly managed to get it partially working with React Hot Loader 3.0-beta.2 although my stores are resetting back to initial state
I can modify component class methods though with markup and css reloading which is good!
I'll look into mobx-model thanks!

https://gist.github.com/rej156/4524b59ea77a697fb62a39eada5b9bbe
Managed to get it working, I deserialized my es6 class stores using JSON.stringify 👍

(Personally I gave a little bit upon HMR though, to often issues with
decorators not being picked up etc, not being able to use stateless
functional components etc, so for just HMR itself I wouldn't go through
this trouble)

Small note: HMR is the transport that gets updated JavaScript into the browser. It is not the thing that detects React components or patches them. Vanilla HMR API just lets you say that module A knows what to do when a module B is updated.

@gaearon you are right, this comment is a bit short through the corner, I still use webpack HMR for reloading the app, but not anymore to preserve the state of React components, it is doable (see the mobx docs), or even app state at all.

It can all be done, but personally I'm fine nowadays with an automated full refresh of the app, instead of trying to recover state. Routing is usually enough to bring me almost at the same state again. I'm in favor of thinking instead of trying anyways when developing ;-).

A related problem I'm having right now is that hot reloading React components that have @computed class properties breaks. Patching doesn't skip them and an error happens because they are "get" only.

This might also be useful for others reading this issue: https://gist.github.com/rej156/4524b59ea77a697fb62a39eada5b9bbe

Thanks to @rej156 now I updated my stack too with the hot-reloadable mobx stores:
https://github.com/foxhound87/rfx-stack

Thanks for sharing @foxhound87!

Is there any problem with this code in index.tsx?

if (module.hot) {
  module.hot.accept();
}

// Type definitions for webpack (module API) 1.13
interface Hot {
/**
* Accept code updates for this module without notification of parents.
* This should only be used if the module doesn’t export anything.
* The errHandler can be used to handle errors that occur while loading the updated module.
* @param errHandler
*/
accept(errHandler?: (err: Error) => void): void;

I don't have any problem including hot-reload es6 class store

Was this page helpful?
0 / 5 - 0 ratings