fix: check whether oldDom is present in the DOM
#4318
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📊 Tachometer Benchmark ResultsSummaryduration
usedJSHeapSize
Results02_replace1k
duration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
03_update10th1k_x16
duration
usedJSHeapSize
07_create10k
duration
usedJSHeapSize
create10k
duration
usedJSHeapSize
filter-list
duration
usedJSHeapSize
filter_list
duration
usedJSHeapSize
hydrate1k
duration
usedJSHeapSize
hydrate1k
duration
usedJSHeapSize
many-updates
duration
usedJSHeapSize
many_updates
duration
usedJSHeapSize
replace1k
duration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
text-update
duration
usedJSHeapSize
text_update
duration
usedJSHeapSize
todo
duration
usedJSHeapSize
todo
duration
usedJSHeapSize
update10th1k
duration
usedJSHeapSize
|
JoviDeCroock
requested review from
developit,
andrewiggins and
marvinhagemeister
|
Size Change: +42 B (0%) Total Size: 60.3 kB
ℹ️ View Unchanged
|
marvinhagemeister
approved these changes
Apr 5, 2024
This was referenced Apr 8, 2024
Merged
|
@JoviDeCroock I'm experiencing the insertBefore error on the latest preact on a list that gets frequently changed. Unfortunately I cant provide a stable reproduction steps. |
|
@bagratinho I'd love to have a reproduction but yes, nested fragments or components that just return children are fragment-like. |
|
I started seeing errors similar to what @bagratinho is mentioning as well, and in my case is related to Google Chrome's auto translation. I put together a minimal reproduction that seems to trigger in the REPL env as well. This doesn't throw an error with 10.20.1, but does when using >=10.20.2 import { render, h } from 'preact';
import { useState, useEffect } from 'preact/hooks';
const Button = (props) => {
return (
<div>
<p>hello {props.label} there</p>
</div>
);
};
function App() {
const [, setValue] = useState(0);
useEffect(() => {
const interval = setInterval(() => setValue((v) => v + 1), 1000);
return () => clearInterval(interval);
}, []);
return (
<>
<h1>Hello</h1>
<Button label="Next" />
</>
);
}
render(<App />, document.getElementById('app'));
I narrowed it down to this tag for when the issue started happening https://github.com/preactjs/preact/releases/tag/10.20.2 so that's why I'm assuming this commit is related. Let me know if you want me to migrate this to an issue for better tracking |
|
Thank you both for the input, I will try and look at the translate example. If you find one without it as the first message here implies please share 🙏 |
|
@andrewburgess I would encourage you to try out #4409 if possible |
|
@JoviDeCroock checked it out and seems to solve the issue, thanks for looking into it! |
1 task
2 tasks
This was referenced Aug 14, 2024
This was referenced Sep 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #4194
This was a bit of a tricky one and haven't been able to reproduce this in tests but the base case looks like the following
The main issue is that in nested fragment-like children we can have a very deep chain of components where the last one eventually resolves to unmounting the children. This is problematic because we bubble back up to the
_parentwhere the_nextDom/oldDomis already set but can be unmounted by a laterFragment-likechild.This effectively means that _nextDom on all parents is going to be invalid, we however can't course-correct as we've already higher-up in the stack assigned oldDom which now in-turn can become invalid by the first call to diff.
My naive solution for this is to check
isConnectedand get a new DOM-Sibling, this re-checks the children and shouldn't come up with an old-node as we are post-diff. Open to any other solutions here.For debugging I copied the sandbox attached in the issue in our
demoand logged that way.