"Updating state inside a derived or logic block expression is forbidden" inside { @html function_that_modifies_state() }

[xl0]

Describe the bug

This fails:
https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAA41RsW7cMAz9FYbNYCOG3dm9HGp0aIdkc7tUHXQ2hRMqU4JEJw0M_3shX-8uaDp0IvhIPr5HLmiso4Tt9wVZT4QtdiFghfIScpKeyAlhhcnPccjILg3RBtkrVmKn4KNAHzVn9EBgop9AYd1csfrEoTBPOBIY_MwC93CbRAsV78sPis-1dMWXkXULCj93fd996hSuZe5SvGuuEnh5Zw2kemS95urulZaD5bFN0OwVL401q2KscPKjNZZGbCXOtFYX29fB_3T_R_GySc679MFRUa45DdGHVJyNmZkHsZ5BLjt6_6V_fChKWDZPYg0UN6mOrC-QkqaBbxRfgH4F4mSfCHygqDeqIuiYCCYdf47-meHZyhE0OC_gDRgfp9npVIJliKQd6BCcHbR4fsXeHwkipdkJ2ASDHo401uf6pgbuQeEu7BXC3enMdaTg9ECdc4XCXmEFCr8qLOEutza590SxnkIkmSPDRpeR9e8PfjzK5P5xm_Xtu36svwGcihQnsQIAAA==

My workaround is to not call the function from {@html }, but rather use $effect to calculate the value:
H4sIAAAAAAAAA41SwY7TMBD9lWHYQ6KNEs6lrYg4wAFugQvm4CZj1cIZW_Zkl1WUf0dOaLtSOXCy_GbmzXvPntFYRwl3P2ZkPRLusA0BK5SXkC_piZwQVpj8FPuM7FMfbZCjYiV2DD4KdFFzRk8EJvoRFNbNDas3DoV5wpFA7ycWOMBDEi1UvCvfK77U0g2fB9Y7UPip7br2Y6twKXOX4n1zk8DzW2sg1QPrJVf3r7ScLA

Offending component code:

<script>
	let {s = $bindable()} = $props();

	function transcribeToHTML() {
		if (!s.rna) {
			// Very expensive operation (parse markdown with a lot of formulas) in real applicaton
			// The result is cached.
			s.rna = "<p>" + s.dna.replaceAll("T", "U") + "</p>"
		}
		return s.rna
	}
</script>

{@html transcribeToHTML()}

which is included inside {#if } in the parent.

I'm not sure if this is a bug or I misunderstood something.

Reproduction

run in playground

Logs

No response

System Info

.268, playground

Severity

annoyance

[Conduitry]

This was changed very recently in #13625. Maybe the error message needs adjusting if the intent is that state modifications aren't allowed from the template at all, not just from logic blocks.

[xl0]

I fee the check is overly broad - I'm getting the same error from very benign-looking code that just passes a string value down to a component that binds it to an editable

. And it's not even consistent, I'm only getting it under some unknown conditions.

[paoloricciuti]

I mean you are technically updating state from a block (the html block). This could very easily go wrong. Can you provide some more examples of code that generate problems?

[trueadm]

You most definitely should not be mutating state inside a @html block, that's why this change was introduced.

And it's not even consistent, I'm only getting it under some unknown conditions

If you can provide repos, we can improve the consistency and fix any issues there might be there :)

[xl0]

@trueadm I think the issue is, it's not clear where you are allowed to mutate the state.
It should be something obvious, or there's going to be a lot of confusion. In Svelte 4, this {@html mutator() } pattern just worked without any issues.

I really like explicit runes vs let, but at times the behavior is just not obvious. Sure you can document it, but ideally it would b e obvious without documentation. I don't have a solution in mind though. Maybe something with type annotations?

Let me try to reproduce and isolate the other instance of this issue I saw.

[paoloricciuti]

@trueadm I think the issue is, it's not clear where you are allowed to mutate the state.
It should be something obvious, or there's going to be a lot of confusion. In Svelte 4, this {@html mutator() } pattern just worked without any issues.

Not inside deriveds and not inside blocks (basically either in the test of an if block, or in the arguments of an each etc etc

[xl0]

Fair enough, no mutation in condition or #each, that's an easy rule to follow, and it makes intuitive sense.

Why not inside {@html} though?

<p>{ mutator() }</p> this works.
{ @html mutator() } this does not work.

[paoloricciuti]

Fair enough, no mutation in condition or #each, that's an easy rule to follow, and it makes intuitive sense.

Why not inside {@html} though?

<p>{ mutator() }</p> this works. { @html mutator() } this does not work.

Html is still a block effect...I wonder if we should prevent also in template effects. But that's just a random idea, I think we need to evaluate the pros and cons

[trueadm]

{ @html mutator() } this does not work.

We can of course enforce that too, but then it might get complicated around the messaging.

[Conduitry]

Allowing {mutator()} but not {@html mutator()} strikes me as weird. As a user, I don't see the latter as any more of a 'logic block' (per the error message) than the former.

[trueadm]

I put up a PR that treats template expressions with the same error.

[xl0]

@trueadm Please consider the other direction - allow mutations in as many places as possible, and then implement a compile time warning drawing the users attention to the fact that they are pointing a shotgun at their foot.

This patterns Just Works ™️ in Svelte 4. Keeping it working would make the transition easier.

[paoloricciuti]

@trueadm Please consider the other direction - allow mutations in as many places as possible, and then implement a compile time warning drawing the users attention to the fact that they are pointing a shotgun at their foot.

This patterns Just Works ™️ in Svelte 4. Keeping it working would make the transition easier.

It can't be a compile time check because we could have no visibility inside the function. Mutating inside the template is rarely useful and the same "effect" could be achieved in better ways.

[trueadm]

This patterns Just Works ™️ in Svelte 4. Keeping it working would make the transition easier.

It will continue to work in non-runes mode. What Svelte 4 was doing was the source of so many issues, so it's rightfully an error now – having it as a warning will just let people ignore it, which in turn leads to more issues further on down the line.