HMR for local development #1547
Replies: 5 comments
|
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 |
|
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 - webcomponents-cg/community-protocols#6 |
|
Could be a good article for reference |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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
All reactions