-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Buggy @html tag on page load/refresh #6832
Comments
I cloned your repo and did a few tests. Here are my findings so far:
I'm running out of time right now before I need to go do something else, but I'll come back to this. In the meantime, I'm posting these incomplete findings so that anyone else who wants to troubleshoot this will have a starting point to work from. |
Okay, I'm pretty sure I've identified the precise cause of the bug. I'm not familiar enough with the Svelte code to fix the bug, but I know why it's happening, which will hopefully give the Svelte maintainers a head start on writing a fix. When Svelte compiles your repro to Javascript code, it looks like this: function create_fragment(ctx) {
let t0;
let t1;
let html_tag;
let t2;
let t3;
const block = {
c: function create() {
t0 = text(/*a*/ ctx[1]);
t1 = space();
html_tag = new HtmlTagHydration();
t2 = space();
t3 = text(/*c*/ ctx[0]);
this.h();
},
l: function claim(nodes) {
t0 = claim_text(nodes, /*a*/ ctx[1]);
t1 = claim_space(nodes);
html_tag = claim_html_tag(nodes);
t2 = claim_space(nodes);
t3 = claim_text(nodes, /*c*/ ctx[0]);
this.h();
},
h: function hydrate() {
html_tag.a = t2;
}
// Rest of block omitted for space
}
} When the component is created by client-side Svelte code (for example, when you load a different page and navigate to the page with this component, or after HMR), the Here's the HTML that's produced by the server-side rendering, exactly as it was delivered to the browser (including the extra newlines and one line that's nothing but three tabs and a newline): <div id="svelte">
1 <!-- HTML_TAG_START -->2<!-- HTML_TAG_END --> 3
</div> There's more HTML, of course, but that's the important part for understanding the cause of this bug. You'd think that this would produce the same node structure as
Notice how the first and last text nodes don't just contain "1" and "3", they contain "(whitespace)1(whitespace)" and "(whitespace)3(whitespace)". That's the root cause of this bug. The way the rest of the bug plays out is that the line function claim_text(nodes, data) {
return claim_node(nodes, (node) => node.nodeType === 3, (node) => {
const dataStr = "" + data;
if (node.data.startsWith(dataStr)) {
if (node.data.length !== dataStr.length) {
return node.splitText(dataStr.length);
}
} else {
node.data = dataStr;
}
}, () => text(data), true);
} When What should have happened here was that the SSR should have returned a div with no extraneous whitespace around the contents. Instead of the HTML I linked above with several blank lines around the But instead, because the But the root cause of the bug is the extraneous whitespace before the text node "1", because that made the To solve this bug, the SSR needs to not render extraneous whitespace around the contents of |
Thank you for the excellent investigation @rmunn !! CC @tanhauhau who has been tracking whitespace issues |
Hey, I haven't looked at Svelte in a while and I have not analyzed this issue in detail, but I feel this issue might be connected to a @rmunn if I remember correctly, the Additionally, errors in claims generally don't result in correctness problems (but of course, this might not be the case with this particular issue). After the claim phase, all nodes that were originally on the page but were left unclaimed are deleted, and nodes that we want to claim but were unable to find on the page are newly created (and placed in the positions that we expected them to be). So whitespace issues as you describe generally only lead to performance problems (having to delete a node that we could have claimed, and creating a new node since we couldn't claim any node) rather than correctness problems (after nodes have been deleted, created, and repositioned, the page looks as we expect). Your description of wrong nodes getting claimed, erased, changed, reordered is actually expected behavior (even though it is weird and not that performant). It would, however, certainly be cool to have even better What is weird here in this issue is that |
Is this issue fixes? I encountered a similar problem using svelte 4 |
Svelte 4.0.4 added some hydration fixes, so if you're using Svelte 4, please make sure you're testing with the latest version and let us know if it works with that specific version |
I'm using the latest version: svelte 4.0.5 Here's a replicate: https://www.sveltelab.dev/tfpbg025yxmqvpd is this svelte or the library @macfja/svelte-persistent-store? Update: This seems to be a problem with svelte and not the library. |
Is this issue a duplicate of #8213 ? |
Have updated the minimal reproduction https://github.com/kelvinsjk/sveltekitHTMLTag to run on svelte 4.0.5 and the whitespace claiming hydration problem as described in the original issue ticket is still present |
Here's a live demo of your repository: https://www.sveltelab.dev/0lxbt6lnamtzq1f |
I also have this problem in combination with an i18n solution which returns HTML. Translations for normal elements are coming but HTML is missing often. Hopefully this could be fixed, soon. |
Describe the bug
The @html tag is buggy on initial page load/refresh.
For example, in the reproduction repo (https://github.com/kelvinsjk/sveltekitHTMLTag), we have
const a = 1, b = 2, c = 3
and{a} {@html b} {c}
.The SSR rendered page correctly shows
123
but upon page load and hydration it becomes13
instead.On HMR it then works as intended, and certain combination of text around those tags could lead it to work as well, but other times it doesn't.
Reproduction
https://github.com/kelvinsjk/sveltekitHTMLTag
Logs
No response
System Info
Severity
annoyance
Additional Information
Can be worked around by re-assigning the variable in action onMount, but rather annoying as I haven't been able to discern a pattern as to when this will strike.
The text was updated successfully, but these errors were encountered: