svelte

Commit Graph

Author	SHA1	Message	Date
Rich Harris	0adc22c9ae	fix: defer batch resolution until earlier intersecting batches have committed (#17162 ) This fixes an awkward bug with `each` blocks containing `await`, especially keyed `each` blocks. If you do `array.push(...)` multiple times in distinct batches, something weird happens — to the `each` block, the array looks this... ```js [1] ``` ...then this... ```js [undefined, 2] ``` ...then this... ```js [undefined, undefined, 3] ``` ...and so on. That's because as far as Svelte's reactivity is concerned, what we're _really_ doing is assigning to `array[0]` then `array[1]` then `array[2]`. Those (along with `array.length`) are each backed by independent sources, which we can rewind individually when we need to 'apply' a batch. When it comes to sources that actually _are_ independent, this is useful, since we apply the changes from batch B to the DOM while we're still waiting for a promise in batch A to resolve. But in this case it's not ideal, because you would expect these changes to accumulate. In particular, this fails with keyed `each` blocks because duplicate keys are disallowed (assuming the key function doesn't break on `undefined` _before_ the duplicate check happens). This PR fixes it by stacking batches that are interconnected. Specifically, if a later batch has some (but not all) sources in common with an earlier batch, then when we apply the batch we include the sources from the earlier batch, and block it until the earlier batch commits. When the earlier batch commits, it will check to see if doing so unblocks any later batches, and if so process them. In the course of working on this I realised that `SvelteSet` and `SvelteMap` aren't async-ready — will follow up this PR with ones for those. Fixes #17050 --------- Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com> Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>	5 months ago
github-actions[bot]	25a1c5368b	Version Packages (#17842 ) This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## svelte@5.53.7 ### Patch Changes - fix: correctly add \_\_svelte_meta after else-if chains ([#17830](https://github.com/sveltejs/svelte/pull/17830)) - perf: cache element interactivity and source line splitting in compiler ([#17839](https://github.com/sveltejs/svelte/pull/17839)) - chore: avoid rescheduling effects during branch commit ([#17837](https://github.com/sveltejs/svelte/pull/17837)) - perf: optimize CSS selector pruning ([#17846](https://github.com/sveltejs/svelte/pull/17846)) - fix: preserve original boundary errors when keyed each rows are removed during async updates ([#17843](https://github.com/sveltejs/svelte/pull/17843)) - perf: avoid O(n²) name scanning in scope `generate` and `unique` ([#17844](https://github.com/sveltejs/svelte/pull/17844)) - fix: preserve each items that are needed by pending batches ([#17819](https://github.com/sveltejs/svelte/pull/17819)) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	6 months ago
Rich Harris	7717ba01b4	fix: preserve each items that are needed by pending batches (#17819 ) This fixes a longstanding TODO with each blocks: currently, if any effects aren't used in the current batch at the moment of reconciliation, they are destroyed. Subsequent batches therefore end up recreating them. This is wasteful at the best of times, but if the effect contains any async work, that work has to be restarted. This PR fixes it by preserving any effects that correspond to the keys of pending batches. It _does_ mean that we need to iterate over each `keys` map for each pending batch in which an each block re-ran, but that is a rare scenario. This feels preferable to the alternative approaches.	6 months ago

Author

SHA1

Message

Date

Rich Harris

0adc22c9ae

fix: defer batch resolution until earlier intersecting batches have committed (#17162 )

This fixes an awkward bug with `each` blocks containing `await`,
especially keyed `each` blocks.

If you do `array.push(...)` multiple times in distinct batches,
something weird happens — to the `each` block, the array looks this...

```js
[1]
```

...then this...

```js
[undefined, 2]
```

...then this...

```js
[undefined, undefined, 3]
```

...and so on. That's because as far as Svelte's reactivity is concerned,
what we're _really_ doing is assigning to `array[0]` then `array[1]`
then `array[2]`. Those (along with `array.length`) are each backed by
independent sources, which we can rewind individually when we need to
'apply' a batch. When it comes to sources that actually _are_
independent, this is useful, since we apply the changes from batch B to
the DOM while we're still waiting for a promise in batch A to resolve.
But in this case it's not ideal, because you would expect these changes
to accumulate.

In particular, this fails with keyed `each` blocks because duplicate
keys are disallowed (assuming the key function doesn't break on
`undefined` _before_ the duplicate check happens).

This PR fixes it by stacking batches that are interconnected.
Specifically, if a later batch has some (but not all) sources in common
with an earlier batch, then when we apply the batch we include the
sources from the earlier batch, and block it until the earlier batch
commits. When the earlier batch commits, it will check to see if doing
so unblocks any later batches, and if so process them.

In the course of working on this I realised that `SvelteSet` and
`SvelteMap` aren't async-ready — will follow up this PR with ones for
those.

Fixes #17050

---------

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>

github-actions[bot]

25a1c5368b

Version Packages (#17842 )

This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.


# Releases
## svelte@5.53.7

### Patch Changes

- fix: correctly add \_\_svelte_meta after else-if chains
([#17830](https://github.com/sveltejs/svelte/pull/17830))

- perf: cache element interactivity and source line splitting in
compiler ([#17839](https://github.com/sveltejs/svelte/pull/17839))

- chore: avoid rescheduling effects during branch commit
([#17837](https://github.com/sveltejs/svelte/pull/17837))

- perf: optimize CSS selector pruning
([#17846](https://github.com/sveltejs/svelte/pull/17846))

- fix: preserve original boundary errors when keyed each rows are
removed during async updates
([#17843](https://github.com/sveltejs/svelte/pull/17843))

- perf: avoid O(n²) name scanning in scope `generate` and `unique`
([#17844](https://github.com/sveltejs/svelte/pull/17844))

- fix: preserve each items that are needed by pending batches
([#17819](https://github.com/sveltejs/svelte/pull/17819))

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Rich Harris

7717ba01b4

fix: preserve each items that are needed by pending batches (#17819 )

This fixes a longstanding TODO with each blocks: currently, if any
effects aren't used in the current batch at the moment of
reconciliation, they are destroyed. Subsequent batches therefore end up
recreating them.

This is wasteful at the best of times, but if the effect contains any
async work, that work has to be restarted.

This PR fixes it by preserving any effects that correspond to the keys
of pending batches. It _does_ mean that we need to iterate over each
`keys` map for each pending batch in which an each block re-ran, but
that is a rare scenario. This feels preferable to the alternative
approaches.

3 Commits (async-derived-coordinate-batches)