Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Hooks for granular HMR support #2377
Follow up to recent conversation on discord regarding v3 support for HMR.
Let me list out the steps we need for a successful hot reload, and then maybe we can discuss if the core needs to change, or whether we can just monkey-patch stuff.
I'm going to gloss over the component resolution part, as I think we already have that handled in the v2 HMR code.
These steps happen when a hot reload process starts:
Get the current state of the component and keep it somewhere.
Get the position in the DOM where the component is mounted
Destroy the old component
Render updated component in place of the old component
Apply state from old component on to the new component
I'll need your help/direction on step 1 and step 5.
Thanks, this is very useful. The
One thing I haven't wrapped my head round is if there are any subtle timing considerations around
I think the proposed
The only thing I forgot mention in the OP is...
Couple of things here are very useful/desirable in live cases too:
If for some reason one or both of these are not surfaced as part of the public api, then to have them unofficially available would be very much appreciated, pretty please
Using webpack I get sapper-dev-client.js errors on
Edit: this is when using the Sapper template which sets hotReload: false and links to this issue.