tick() doesn't seem to work

[FirstProphet]

Describe the bug

The code below is supposed to change the clientHeight of the div when the button is pressed and then console.log the original and the new height. According to the svelte documentation, you can "use tick to ensure that the UI is updated before continuing". But it doesn't work and still console.logs the original height. If you replace the tick function call in line 14 with my crude customTick function, it seems to work fine.

Reproduction

<script>
	import { tick } from 'svelte';
	const contents = ['Hello World', 'Hello<br />World'];
	let currentContent = $state(0);
	let clientHeight = $state();

	function customTick() {
		return new Promise((resolve, reject) => setTimeout(resolve, 1));
	}
	
	function changeContent() {
		console.log(`Client Height Before Change: ${clientHeight}px`);
		currentContent = (currentContent + 1) % 2;
		tick().then(() => console.log(`Client Height After Change: ${clientHeight}px`)); // Doesn't work
	}
</script>

<button onclick={changeContent}>Change Content</button>
<br /><br />
<div bind:clientHeight style="border: 1px solid red;">{@html contents[currentContent]}</div>

Svelte Playground

Logs

No response

System Info

I used the playground on svelte.dev

Severity

annoyance

[Prinzhorn]

tick() does seem to work as documented, but not as you expect. Add console.log(document.querySelector('div').clientHeight); and you'll see that tick runs after @html was updated.

However, the bind:clientHeight binding will then be triggered later by the ResizeObserver. It is not controlled by Svelte's update loop. tick refers to waiting for state changes to be applied to the document.

I don't know what you are trying to achieve, but coupling all this logic so tightly seems like a bad idea. Maybe you can react to clientHeight in an $effect and not try to imperatively do something with the change after updating currentContent? If you think about it they are not related 1:1, because clientHeight can also change when the users changes font size or resize the browser.

[FirstProphet]

Hmm ok I see your point. Although it really seems like it should be possible without using $effect() somehow. Having to resort to using an $effect() kind of bugs me here because I want to listen to a change in clientHeight; I'm not really concerned with what the absolute value is (imagine a scenario in which I wanted to console.log() the difference in height. That would be very awkward to implement with an §effect)

That being said, since you said the ResizeObserver is the problem, I thought of using getBoundingClientRect().height instead of clientHeight and this does seem to work.

[leonidaz]

Since size binding is now using a ResizeObserver, the changed size will only be reflected on repaint. So, await tick() will not work.

requestAnimationFrame() also doesn't work in this case, although I've seen it work in other use cases, such as removing one word at a time from a div - requestAnimationFrame works

The only reliable way aside from setTimeout or element.clientHeight or element.getBoundingClientRect() that I found is to add own ResizeObserver before attempting to change the size and in the callback check the updated bound sizes, like so - with ResizeObserver

Perhaps just to document this behavior and give an example of using own ResizeObserver or tick() with element.clientHeight or element.getBoundingClientRect() in rare cases where you can't just use an $effect()

[leonidaz]

actually, assuming change happens, using and inline$effect.root with a nested $effect could also work

[seantiz]

did bind: previously work differently in 4? As in: was it all handled in the compiler logic without the browser engine's API involved?

I have no opinion on either approach if they've been made different, I'm just trying to understand if there's been a change and if this could catch me out often.

[leonidaz]

did bind: previously work differently in 4? As in: was it all handled in the compiler logic without the browser engine's API involved?

I have no opinion on either approach if they've been made different, I'm just trying to understand if there's been a change and if this could catch me out often.

I believe the bindings for sizes such as clientHeight at some point were using an iframe and then it was switched to ResizeObserver. I believe the Svelte's code behavior itself has not really changed, as in checking the bound clientHeight within a tick() after causing the element size to change would still return the same value.

[seantiz]

did bind: previously work differently in 4? As in: was it all handled in the compiler logic without the browser engine's API involved?
I have no opinion on either approach if they've been made different, I'm just trying to understand if there's been a change and if this could catch me out often.

I believe the bindings for sizes such as clientHeight at some point were using an iframe and then it was switch to ResizeObserver. I believe the Svelte's code behavior itself has not really changed, as in checking the bound clientHeight within a tick() after causing the element size to change, would still return the same value.

I see, thank you.

[dummdidumm]

I'm not really sure in which way we should adjust the documentation here. Tempted to close this as "works as designed, this is an edge case" - any objections?

[leonidaz]

I'm not really sure in which way we should adjust the documentation here. Tempted to close this as "works as designed, this is an edge case" - any objections?

@dummdidumm I think it would be valuable to add a note in the documentation, such as:

Because the `ResizeObserver` api runs on its own schedule, if you're changing an element's contents and need to immediately measure the change in the size dimensions, use the element's DOM methods directly, such as `clientHeight`, `clientWidth`, etc., in the next scheduled microtask via `tick()`.

[dummdidumm]

I don't know - again, this feels like a really big edge case, if we start documenting stuff like this the docs will be unreadable

[harrisi]

How else would one learn about this?

And how many other undocumented edge cases are there? How could there be so many that it would make the docs unreadable?

[seantiz]

I don't have an opinion on updating the Dimensions section of the docs, but the tick() description is now misleading from my POV (I'm saying this as someone who reaches for tick() as one of my favourite Svelte tools)

the tick() description:

you can use tick to ensure that the UI is updated before continuing. tick returns a promise that resolves once any pending state changes have been applied

I think it helps to add even just a one-liner there where it doesn't apply to updates being handled by an external API like ResizeObserver.

[leonidaz]

I don't know - again, this feels like a really big edge case, if we start documenting stuff like this the docs will be unreadable

I've definitely ran into this on more than one occasion with the previous versions of Svelte and basically gave up on using bound sizes, opting to directly work with the DOM.

But it is confusing because this behavior goes against Svelte's reactivity paradigm where typically using tick() is expected to work after ui updates.

It's definitely not a common use case, I agree, but since it's not the expected behavior, I think it's worth noting it.

The docs, albeit a more common use case, already warn about using bound sizes with inline elements.

@dummdidumm At the very least, maybe the team can consider adding a Gotchas section, collapsed by default, where we can add more documentation for edge cases.

I think it helps to add even just a one-liner there where it doesn't apply to updates being handled by an external API like ResizeObserver.

I think tick() does behave as intended, it schedules a microtask within the Svelte's runtime. The issue is with the bound sizes. They are updated via a ResizeObserver which runs on its own schedule, completely outside of Svelte's control.

[seantiz]

I think tick() does behave as intended, it schedules a microtask within the Svelte's runtime.

Then it saves time if the docs describe it as that. Right now they don't mention it.