Hot module replacement?

So I’m going to start with the the premise that Hot Module Replacement™ should be as easy and pluggable as https://github.com/substack/react-starter-hmr, with minimal change to the client application.

This is a rough-guide on what is required to get it set up:

1. Install the dependencies: npm i --save-dev browserify-hmr ud
2. Add the plugin to the browserify/watchify bundler watchify client.js -p browserify-hmr ...
3. Add the ud.defn(...) annotation to the part of the application to show which bits of the program are suitable for hot-reload (per screenshot above)
4. Watch view updates appear insta-matically in the page without losing state

My trouble is that with step 4. I couldn’t find a way with choo to force a re-render of the page’s current state like in the React example. I got close in two different ways - forcing a reboot of the entire app (so reverting to initial state) or views updating the next time they were rendered (not insta-matically).

If anyone knows the secret to getting this set up, please tell! Otherwise if a change is required in choo to facilitate this, let’s figure it out? I think it’s going to be something like exposing a way to call render/re-render, unless I’m missing something!

[bengourley]

I’ve published v1 of both https://github.com/bengourley/choo-resume and https://github.com/bengourley/hot-rld.

@yoshuawuyts hot-rld now supports css too.

[yoshuawuyts]

I’d favor the approach in hot-app-replacement because:

1. it’s simpler to maintain - browserify-hmr has proven to be buggy, and I’ve found it complicated to debug
2. it’s simpler to reason about - people can jump in and write their own implementations / contribute
3. with choo apps it’s an anti-pattern to have state live outside choo; should probably write a bit more in depth about this, but some widgets aside (hey maps) all state should merrily be handled by choo for transparancy
4. watchify performs incremental rebuilds; the cost of then sending the full bundle over the loopback interface is negligable
5. using the approach in hot-app-replacement also works for CSS, removing the need for some different CSS solution

Hah yeah so that’s about it - obviously you’re free to do what you want, but this is my take on it (:

On Wed, Oct 26, 2016 at 6:59 PM Ben Gourley [e-mail] wrote:

Noting down @yoshuawuyts https://github.com/yoshuawuyts hot reload proof of concept here https://github.com/yoshuawuyts/hot-app-replacement/tree/choo

I think this is interesting but as far as I can see it

1. saves app state
2. reloads the entire bundle
3. loads app state
4. re-boots the entire app

?

I think it would be cool if we could leverage these community projects and also benefit from actual hot-swaps of updated modules, rather than sending the entire bundle. I can see the benefit of the entire reload, if any views have any state that’s not stored in a model obviously this would help.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/yoshuawuyts/choo/issues/295#issuecomment-256412122, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWlevJdm_Fim_PYDb7PCOyMZA_EJYznks5q34bUgaJpZM4KhBw_ .