(core) - map old VNodes to new ones #236
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was kindly reported by @iFwu this is the second part of this bug-report https://github.com/iFwu/prefresh-bugs-reproduce
This mainly happens in esm-hmr, let's visualize what's happening here, information about esm-hmr can be found here.
When we update
Counter.jsx
, the child ofInternal.jsx
we do the following implicitlyimport Counter.jsx?mtime=Date.now()
this will make our babel-functions re-run and register the new type forCounter.jsx
. For in place updates this works great, but when we now updateInternal.jsx
we'll be importing the old variant ofCounter.jsx
since during esm-hmr we have no way to update thisModuleRecord
in place, essentially theCounter.jsx?mtime=Date.now()
is orphaned and disposed instantly.internal.jsx
updates with the old reference, without checking for a new one to exist (byte-cache), this makes it render with the initial code rather than the new.We've solved this by keeping a mapping of old to new functional components, when we see a vnode created with a supposedly old reference we update it to the new one.