-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Client to Handle Reload #11
Comments
Great call, let's definitely support this. Is there a way to detect that you're in a WebExtensions environment? It could also make sense to do some simple automatic checks here, for example: function reload() {
if (window.browser && window.browser.runtime && window.browser.runtime.reload) {
window.browser.runtime.reload();
} else {
location.reload(true);
}
} |
I did a bit more testing (which I should probably have done before making this issue). Coming up with good defaults here is kinda hard. In a WebExtension there are multiple JavaScript execution contexts. There's a background script. This is the entry point of your extension. This script sticks around the entire time the browser is open. It registers hooks for interactions and can launch other kinds of scripts. There are a few types of scripts the background script can start: content scripts and scripts/pages which define extension ui. Source When browser.runtime.reload is called from anywhere (background page, content script or chrome script), the entire extension is blown away and the extension is reloaded. All prior open tabs of pages owned by the extension are closed, the extension is reloaded and they don't come back. If a single execution context receives a message from the server telling it to In either case, I think the default behavior should be Your call though. |
I'm on board with allowing the user to provide a custom
Although you're right to point out that invalidate can be slightly more complex than our current implementation. reloading the page is the easiest way to handle an invalid HMR update, but I believe more complex implementations can handle it by bubbling the event up to a parent and having them handle it. |
Sounds perfect! I have no objections to this proposal! |
@0xcaff |
I ended up giving up on unbundled and using webpack. Webpack is mature today. Mature software can be used in non-mainstream use cases. Hot module replacement works. For my use case, I'm not willing to tradeoff time to use new technology which may be better. Key things when using webpack:
Let me know if that makes sense. Happy to move this conversation elsewhere (email, twitter DM?) if you need help figuring this out. Will post the source code in the future when I eventually open source this. |
Hmm... Cool, I have made a whole build system around gulp.js to serve everything in ES Module, and another version that ES Module is compiled into SystemJS format for Firefox. |
Webpack has this same API essentially. It's called I'm pretty sure this works with ESModules and dynamic imports too. I might be using them too (not sure what ESModules are exactly tbh). |
i also need this feature, i am also with
My real issue is i using special typo for React where is not compatible with HMR. export const myStore= store({
num: 0,
});
export MyModule view(() => (
<button onClick={myStore.num++}>{myStore.num}</button>
)); More info here. For now i found my solution,considering snowpack emit log, you will probably found this funny but here the tricks for Electron and NwJs ! console._log_old = console.log;
console.log = function (msg) {
console._log_old(msg);
if (msg === '[ESM-HMR]') { // your condition logic , for me this is ok....
location.reload();
}
}; 🤣🤢 If you have more clean solution, plz share. |
HMR should be reloading on every update, can you share your console logs / what kind of |
Oh, I also wonder if this line is returning false in your electron environment: Which would then cause our normal reload function to do nothing instead of reloading:
|
@FredKSchott I dont understand what wrong whit my official project where i trying to convert for now with your thecknologie!, There may be a conversion problem (Parcel => SnowPack), I will study all of this and keep you alert. PS: i share the boilerplate public so you can share for student want learn how use Snowpack with Nwjs or Electron! Sorry friend for the inconvenience, it is probably an external problem to your technologies, i will investigate and keep you informed if is necessary. BTW , i fully convert all my projects from |
Thank you for the kind words! |
The current client implementation handles reloading by calling
window.reload
.https://github.com/pikapkg/esm-hmr/blob/07bf62c2ff783a4ea3319c0b2baa3351b65c073c/src/client.ts#L16-L18
This doesn't make sense for WebExtensions where reloading is done by calling
runtime.reload
. I'm sure there are other contexts where you'd want to customize the reload behavior also (electron?).It would be great if there was an API to customize the implementation of this function.
Maybe something along the lines of
The default registered reload handler could be the location one to preserve existing behavior.
The text was updated successfully, but these errors were encountered: