Open thescientist13 opened 5 years ago
This is problematic and would require removing our current live reload solution entirely. The 2(hmr and live reload) would conflict. If I add a new component or change a page-template, or add a new template, I need to re-generate compilation. That can't be done by HMR by default. Currently, by using filewatcher-webpack-plugin we're able to catch that event and run that compile function. But if we turned on HMR it would still continue to live-reload because of the regex we're watching for (any change in our userWorkspace).
One possible solution, but I don't know how viable it is, would be to modify regex for only certain files we live-reload and re-compile. This is tricky.
Interesting thread from React land
Would be cool if this could work with GraphQL as well, but we can certainly develop it, enabled only by a flag, with certain caveats documented; e.g. might not work for all use cases, YMMV, etc.
This cool project from pikapkg https://github.com/pikapkg/esm-hmr
There is some work in the Community Protocols space happening around this discussion that may be worth following up on whenever (if) we get around to this - https://github.com/webcomponents-cg/community-protocols/issues/6
Could be a good article for reference https://bjornlu.com/blog/hot-module-replacement-is-easy
Type of Change
Summary
As opposed to watch / livereload, which refreshes the full browser on each local development change, enabling HRM (hot module replacement) can help speed up local development by only reloading the part of the page, that needs to change, not the whole application.
Details
For example, given a page with an
<input>
(for example):expected: the page would change color, but the text in the input would remain
note: this might require needing to sync with a state management library like redux.