Hyperapp: HMR

[jamen]

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.

[andyrj]

Personally I am used to Webpack HMR so I plan to stick with that, but if I can help somewhere would be glad to pitch in.

I don't see how we could replicate the react-hot-loader style of functionality easily (it relies heavily on components and being able to wrap what is react renders in higher order components) but the amount of code required to wire up vanilla webpack HMR is trivial and framework independent.

If the consensus is hot reloading is a better fit to officially support I am 100% behind what you all think. For those who might be interested in webpack hmr, I am still going to keep the little mixin and my starter which I am creating to learn more about hyperapp. It doesn't have to be apart of anything official.

[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.

[jorgebucaran]

Can you share your dev workflow? Maybe that would help explain why you prefer some tool over another? HMR vs redux-dev-tools, etc. /cc @andyrj @jamen and @whaaaley

[andyrj]

When I have ssr and hydrate cleaned up, I plan on adding persistence support to the hyperapp-redux-devtools mixin, so that it can work better with the live reload setup.

My preferred workflow starts at having one npm script to run a hot module replaced backend, that is also compiling and serving a hot module replaced frontend via webpack. Currently I prefer to have refresh in my browser behave as a full reset. I know that isn't as simple as a live reload setup but it is what I use atm. There isn't any reason I couldn't use live reload, but my boilerplate would have to change and I would need an easy way to reset/refresh if I did.

[jorgebucaran]

@andyrj Thanks for sharing. Don't you think we should prioritize this issue and leave hyperapp/server for later, essentially the opposite order as you mentioned? 🤔

[andyrj]

I didn't see anything actionable here atm, other than the feature add to the mixin. What did you have in mind?

[jorgebucaran]

What did you have in mind?

To simplify an settle on at least one good workflow and publish official package/s we can start putting forward and promoting.

I think that hyperapp/server is good (and very important) to have in the long term, but in the short term, coming up with an HMR/redux-dev-tools, etc., official solution will go a longer way.

[andyrj]

Ok, I can get redux-devtools compatible with live reload pretty easily, can even make the persistence opt out to first support the hyperapp live reload way by default.

[andyrj]

I don't feel like my workflow should be the official, I am more for supporting the simpler workflow @jamen and @whaaaley are proposing.

[jorgebucaran]

So, perhaps the work that need to be done is adding more docs or documenting those mixins repos thoroughly? I, myself, don't know where to start if I want to try HMR/redux-dev-tools/live-reload.

[andyrj]

Ok no problem, can do that for redux-devtools. I thought we were going to not muddy the water with HMR and live-reload. Instead just go with live-reload on docs right?

[jorgebucaran]

@andyrj I thought we were going to not muddy the water with HMR and live-reload.

Really? 🤔

I don't find live reload that useful, but live reload with HMR (so that state persists), that's a different beast.

Currently I prefer to have refresh in my browser behave as a full reset.

And you can still use HMR with that?

---

@andyrj I don't feel like my workflow should be the official...

I am sorry, but I am going to have to disagree here now. I think having an "official" / recommended workflow is doing a great favor to the community and early adopters in hyperapp.

[jamen]

@jbucaran So, the reason I took my approach is to try and satisfy people that use all different types of build systems. This plays into why mine includes no live-reloading, because that requires assumptions about the developer's build system... So I left it open-ended, and you can choose the live-reloading plugin.

I have no experience with module.hot, so that slipped through the cracks on hyperapp-persist and hyperapp-hmr, and later @andyrj discovered that there is not a good way to mix it in, so its not practical to create a single repo for both these concepts.

I'm definitely not saying we shouldn't officially support Webpack's module.hot, as @andyrj has already said he plans to maintain. But, I would like for the default to be something anyone can approach and understand, even if they don't know what a build system is.

I can quote my proposal piece from the original post to try and limit the noise that was around it:

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
   
   
   4. Others?
   
   
3. Setup minimalist examples of each build system using this approach.

Let me know what you both think about this. Ready to make changes at any time.

[jorgebucaran]

@jamen Existing solutions like module.hot and browserify-hmr seem to be traditionally targeted at things where there is no single source of truth.

Why does ~@andyrj's~ hyperapp-hmr exist then?

EDIT:

@jamen I have no experience with module.hot, so that slipped through the cracks on hyperapp-persist and hyperapp-hmr

Oh, now I see you authored the hmr module. Are HMR and module.hot different things? If they are the same then I am pretty confused.

[jamen]

I assume you mean hyperapp-webpack-hmr, because hyperapp-hmr is the one I published (which as mentioend in the original post, was probably improper because it lacks live-reloading).

But I digress. It would be because:

@andyrj discovered that there is not a good way to mix them, so its not practical to create a single repo for both these concepts.

I don't have experience with webpack. I know some people would be more comfortable with hyperapp if they were able to use webpack HMR how they normally do with module.hot, but at the same time hyperapp brings concepts that allow us to put a new angle on this type of tooling... There is also livereloading plugins for webpack that would give you the same effect I think.

[jorgebucaran]

@jamen Help me out here. From your README:

A HyperApp mixin that lets you perform Hot Module Replacement without needing any ties into your build mechanism.

Okay, what about renaming this module then? I am just trying to add some clarity here before this goes out of hand.

EDIT: Grammar.

[jorgebucaran]

Maybe the most confusing ones are:

• https://github.com/andyrj/hyperapp-webpack-hmr
• https://github.com/jamen/hyperapp-hmr

Either we find a way to keep only one, or rename them? 😉😅

[jamen]

I am for renaming it, that was part of my proposal:

1. Rename hyperapp-hmr or move it into hyperapp-persist/all.

I just wanted to sure we were all on board, because the discussion has mainly circulated between me, @whaaaley, and @andyrj, so original post was for sharing the conclusion we came to.

I also don't want to feel like I'm pushing my approach over anyone, so I'm asking if this persist state + choose livereload plugin sounds reasonable.

[jorgebucaran]

@jamen Thanks for clearing that up. Please move (rename means more maintaining so...) as you wish. Just one pet peeve, "/all" does not strike me as very obvious at first sight. Why that name?

EDIT: Grammar.

[jamen]

With hyperapp-persist you have a more free control over the previous state. Say for example, you wanted to restore a video time, and do it when the user clicks a confirm button. This is something you'd do in production.

This is different from persisting all the state when the app loads, to give the effect of hot-reloading the actions, view, events, etc. while preserving the entire state. Something you'd do during development

[jorgebucaran]

Okay, let's close here after you've decommissioned the package and #276 is merged.

Thanks! 👋

[andyrj]

@jbucaran

And you can still use HMR with that?

Yes with webpack HMR does not refresh the browser, so state doesn't have to be stored in localStorage and refresh can act as a reset switch of sorts.

I am sorry, but I am going to have to disagree here now. I think having an "official" / recommended workflow is doing a great favor to the community and early adopters in hyperapp.

I did not mean we should not have a recommended workflow, just that it should be what @jamen and @whaaaley are pushing for and not my webpack specific workflow.

@jamen

I also don't want to feel like I'm pushing my approach over anyone, so I'm asking if this persist state + choose livereload plugin sounds reasonable.

Don't think you are and hope my discussion on this topic didn't make you feel that way. I am 100% behind the live reload approach for simplicity and broader build tool support.

[jorgebucaran]

@andyrj How are we standing here after https://github.com/hyperapp/hyperapp/commit/599c33dd13fa9c30a50a42809251f5fa91733b29?

@jamen Last I heard you said you'd wrap all the modules into a hyperapp-reactor package a-la Elm. Is that correct?

[andyrj]

@jbucaran the hydration just effects webpack-hmr and makes it so the dom doesn't flicker from being wiped. And hydration should also allow for uncontrolled inputs to persist what value they have through hmr.

[jorgebucaran]

Great! So what should we do to be able to close here? Do you think we could we make a few goals or roadmap? 🤔:smile:

[andyrj]

I think we are good to close here since @jamen is making a different package for the live reload stuff.

[jamen]

That is correct. To sum up what I want to do:

• hyperapp-reactor/hot-reload: Mixin to persist state between sessions
• hyperapp-reactor/timeline: Mixin to take snapshots of state changes for rewinding
• hyperapp-reactor: A little debugger tool that wraps the mixins together

[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?

[whaaaley]

I'm with luke here. hot-reload isn't hot reloading anything at all. persist would be better.

[jamen]

Sure, I can go with hyperapp-reactor/persist.

[jorgebucaran]

Don't fear renaming things if that means we can end up with a clearer and simpler API. Just my 7 cents.