hydration_html_changed bug

[nevis2us]

Describe the bug

"If the {@html ...} value changes between the server and the client, it will not be repaired during hydration, i.e. the server value will be kept. That’s because change detection during hydration is expensive and usually unnecessary."

This is just plain wrong. Especially when using adapter-static, where ssr pages reflect the data fetched at build time. There's also a real life situation where an ssr page would use mp4 with plain html5 video tags and the client-side version would be videojs and m3u8 streams. Or ssr pages might contain separate images instead of carousels/sliders on the client. I believe the framework should handle such cases.

I do care about performance, but not at the expense of data consistency. The hydrated page DOM must match the current data. Period. At the very least, please make it an option which could be set in svelte.config.js.

Thank you for your attention.

Reproduction

I think the use case is obvious and doesn't require much effort to reproduce.

Logs

System Info

System:
    OS: Linux 6.1 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (4) x64 AMD A8-9600 RADEON R7, 10 COMPUTE CORES 4C+6G
    Memory: 1.40 GB / 7.21 GB
    Container: Yes
    Shell: 5.2.15 - /bin/bash
  Binaries:
    Node: 18.20.8 - /usr/bin/node
    npm: 10.8.2 - /usr/bin/npm
  Browsers:
    Chrome: 136.0.7103.113
    Chromium: 136.0.7103.113
  npmPackages:
    svelte: ^5.25.7 => 5.25.7

Severity

blocking an upgrade

[paoloricciuti]

1. Please be more polite next time.
2. If you really really need this there's an easy workaround which you can find in the migration guide (and maybe we should include in the error as well)

<script>
	let { markup, src } = $props();

	if (typeof window !== 'undefined') {
		// stash the values...
		const initial = { markup, src };

		// unset them...
		markup = src = undefined;

		$effect(() => {
			// ...and reset after we've mounted
			markup = initial.markup;
			src = initial.src;
		});
	}
</script>

{@html markup}
<img {src} />

Thanks for reporting but we are gonna close this.

[nevis2us]

Any reasons not to fix this, other than some obscure concerns about expensiveness?

[paoloricciuti]

Any reasons not to fix this, other than some obscure concerns about expensiveness?

Because as we said the value rarely change between server and client, checking at runtime is a performance overhead and if you know it will change you have a way to force it.

[nevis2us]

the value rarely change between server and client

As I mentioned above, this is not the case with adapter-static, which is capable of rendering pages client-side based on current data, provided that hydration works as expected, and when configured with SPA fallback, can even render pages that haven't been prerendered on the server. To work around this bug, I have to replace every {@html ...} tag with a component with the aforementioned code which is clumsy, unnecessary, and produces hydration_mismatch warnings.

[paoloricciuti]

What I meant is that in most applications the server and client html is the same, in this very specific case it is not and you still have a way to fix it... I'm pretty sure you can also write an utility function for that.

The whole point is that it's not worth to slow down everybody else code for a niche use case who still have a way of achieving the same result

[nevis2us]

in most applications the server and client html is the same

Then most applications won't be affected by an "expensive" fix. Adapter-static is officially supported and in many cases would be a better choice than running nodejs in hostile production environments. Data consistency IS important and the framework has been plagued by hydration bugs for years. Sooner or later you will have to fix this if you want it to succeed. I do.

[paoloricciuti]

Then most applications won't be affected by an "expensive" fix

That's the problem: to repair hydration in case there's one you will need to march the whole dom created on the server...and if in the end nothing changed you did it for nothing. Since there is a way to prevent this in the rare case you need it there's no need to punish all the apps that don't need it.

[nevis2us]

Ok, thanks. I'll probably have a look at the svelte code to figure out how this works. What's confusing is that fairly complex changes to the dom are successfully repaired during hydration, but the contents of some @html tags, which are mostly plain text with some basic markup like <span>, <b>, <a>, etc., are not.

[MotionlessTrain]

Svelte uses hydration markers in the html (looking like small comments), to help the hydration code to know where everything is. Those are not present within the code in @html (and cannot be, as there could be something else than html inside of that too), which means that it is not as fast to compare the html

[nevis2us]

it is not as fast to compare the html

Excuse my ignorance, but why do you need to compare the contents of @html tags at all? Why not just plug the new value into the client dom?

[7nik]

Because that will reset the state of elements like <input>, if the user was fast enough to change it, and restart presented animations and transitions.

[nevis2us]

import {browser} from '$app/environment';
...
{#if browser}
	{@html caption}
{:else}
	{@html caption}
{/if}

This "workaround" also works, but looks kinda silly. I'm still under the impression that the compiler can do such things for me)

I've finally figured out how to reproduce the issue I'm having on the dev server, and now I'm getting hydration_attribute_changed warnings about other attributes too and threats to ignore the client values, but thankfully they are still updated during hydration. The same goes for the compiled version.

I have a news block with top 6 news fetched from the backend. These are basically inline images/videos with captions and links to the articles. Right now the issue seems to be limited to the contents of the @html tags which can be easily repaired either with the above "fix" or the one from the docs, but hydration_attribute_changed warnings give the impression that this might change in the future. Adapter static worked pretty well for me so far but if this happens I would have to run nodejs in a fbsd jail which is my production environment. Hope this works.

[paoloricciuti]

The attribute changed warning should be just for attributes that causes a fetch call (like an img src)

I'm still under the impression that the compiler can do such things for me

Again the problem is not that is difficult to do, it was a conscious design choice for the reasons I gave above.

[nevis2us]

I ended up with the following code which doesn't cause any hydration issues with adapter static and is much better performance-wise as requests to the backend might take up to several seconds depending on server load:

{#await Promise.all([runtime requests to the backend])}
	<Component {build time data} />
{:then [runtime data]}
	<Component {runtime data} />
{/await}

Build time requests to the backend would have to be resolved in +page.js for this code to work and the pending branch of {#await ...} to be rendered during ssr:

[build time data] = await Promise.all([build time requests to the backend]);

Thanks everyone.