feat: use linked lists for each blocks

[Rich-Harris]

This replaces the current implementation of {#each ...} blocks with a linked list implementation.

What this means is that rather than constantly replacing state.items (which is prone to race conditions that are tricky to accommodate), we update the linked list in place as the value changes. As such, it's easy to handle things like aborted outros in the middle of the list without them being re-appended.

The hard part of list reconciliation algorithms is minimising moves in a direction-agnostic way. For example, if a list changes from ABCDE to BCDEA, this can easily be accomplished by stashing the existing A, skipping over BCDE (because everything matches), then grabbing A from the stash and moving it to the end.

By the same logic, if we changed from ABCDE to EABCD, we would stash ABCD, match E, then append A then B then C then D — four moves. Ideally, we'd figure out that we can accomplish the same thing by just moving E instead.

Previously, this was accomplished with the help of a longest increasing subsequence algorithm. In this PR, we take a different tack. As we progress through the list, we keep track of consecutive stashed and matched items, and when we encounter a changed item that we previously saw, we decide whether to move items forward or backward based on which list is longer.

So in the ABCDE -> EABCD case:

• at index 0 we stash ABCD then match E, and proceed to the next item in the list
• at index 1 we encounter A, which we've previously seen, so we compare stashed (ABCD) and matched (E) and, because matched is shorter, move E before ABCD
• still at index 1, we find a match (A === A), so we proceed to the next item
• at index 2, B === B, proceed
• at index 3, C === C, proceed
• at index 4, D === D, finish

In this way we're able to reconcile the new data with the existing linked list in what I think is an optimal way. Honestly though, the whole thing is a complete brainfuck and there may be some pathological cases that this struggles with. If anyone with a CS degree has encountered this algorithm before and can speak to its merits/flaws I'd love to hear about them. I haven't benchmarked this against the current implementation (though there are probably some opportunities for further optimisations).

Another change I made: for the sake of my own sanity while working on this, I eliminated the distinction between keyed and indexed each blocks (by turning indexed each blocks into blocks whose key is the index). It's possible that we will need to reinstate that separation to avoid the overhead of creating a useless lookup for indexed blocks.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

⚠️ No Changeset found

Latest commit: 99ecd98

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR