HMR

After talking to @whaaaley and @andyrj, I think that I have misused the term “HMR” in creating hyperapp-hmr.

Put simply, HMR is supposed to make the changes become active the moment that you save the file.

Mine only does half this: It pushes all the state into the next session while everything else is reloaded underneath by your own initiative… This could be just hitting F5 and getting the same HMR benefits, or setting up an auto-reload server to get the entire HMR experience… However, the package by itself doesn’t technically give you “full HMR”.

Existing solutions like module.hot and browserify-hmr seem to be traditionally targeted at things where there is no single source of truth. But, because Hyperapp has this and can provide much cleaner solutions, I want to make a proposal of how we could document this alternative:

1. Rename hyperapp-hmr or move it into hyperapp-persist/all.
2. Document how to use this module alone and alongside livereload packages. For example:
   1. webpack-livereload-plugin
   2. rollup-plugin-livereload
   3. browserify-livereload (even made by one of us, @traducer!)
   4. Others?
3. Setup minimalist examples of each build system using this approach.

Looking at hyperapp-persist and these livereload plugins, this seems like a really good alternative to me! But I understand some people prefer the workflows they are used to and might have less appeal to this. But, I’m still curious what everyone thinks, and I hope I have explained well.

[whaaaley]

I agree with Jamen here. I think we should leverage hyperapp’s single state tree to do minimalistic state persistence and combine it with live reloading. If users are following the rules of hyperapp and have all of their state stored in hyperapp’s single state tree, then as far as they should be concerned this solution is equivalent to “traditional” hot module replacement.

If state persistence and livereload is the route that’s taken I think we should stray away from the term “HMR”. Even though it is a “household” term at this point, that is not what this is, but instead hyperapp’s take on the livereload and state persistence concept.

[lukejacksonn]

FWIW I still call hot-reload “persist” in my head… because that is what it does, it ensures state persists between sessions. Does it incorporate live-reload, is that where I am getting confused?