chore: centralise branch management #16977
Conversation
🦋 Changeset detectedLatest commit: 4efcc52 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
| component.promise = promise; | ||
| // wait for rendering | ||
| await Promise.resolve(); | ||
| await tick(); |
There was a problem hiding this comment.
confession, I don't really understand why this change was necessary. but it was
|
|
||
| if (hydrating) { | ||
| // we want to restore everything _except_ this | ||
| set_hydrating(false); |
There was a problem hiding this comment.
Do we need to re-enter hydration mode after this? (tbh I don't quite understand why we need to check for hydrating at all here; how can you end up there with hydrating being true?)
There was a problem hiding this comment.
Calling restore() will set hydrating back to true if we were initially hydrating. By the time the promise resolves, we've finished hydrating — if we don't set it back to false then all hell breaks loose, because the next time a block effect runs it will enter the wrong code path. Added a comment
| if (this.#legacy && key !== null && typeof key === 'object') { | ||
| key = {}; | ||
| } |
There was a problem hiding this comment.
I don't understand this part - what is it supposed to do? key is not guaranteed to be a primitive outside of key blocks, e.g. for snippet or component it's the render function
There was a problem hiding this comment.
If you have something like {#key array} and do array = array, the block should re-render. For snippets and components typeof key === 'function' so it won't hit this path. Though I guess I could move the logic to key.js
| } | ||
|
|
||
| var target = create_text(); | ||
| anchor.before(target); |
There was a problem hiding this comment.
This could use a comment - why are we creating a text node, make the render function append to that target but then remove that target below?
There was a problem hiding this comment.
This was something to do with offscreen fragments but it turns out we don't need this any more
2 participants
The way we handle branches is kinda broken in an async world. We assume — quite reasonably unless you're in an async world — that it's safe to simply bail out of a block if the expression is unchanged from before. When it's time to commit a block, we commit whichever branch corresponds to the most recent invocation, which isn't correct. And it's only possible to have one offscreen branch per block. And so on. I'm pretty sure there's some memory leaks in there as well.
This PR adds a new
BranchManagerclass, which each block type can use to control which branches are created when. It ensures that branches are correctly linked to batches, and that they're destroyed at the appropriate time. It handles all the complexities around transitions and as-yet-unresolved batches.Currently it's used for
#if,#await,#key,@render,<svelte:component>and<svelte:element>. It might make sense to use it for<svelte:boundary>as well. It does not currently power#eachblocks, which are unique in that their branches aren't mutually exclusive.I'm hoping that this will enable more work towards #16971 and related issues.
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.packages/svelte/src, add a changeset (npx changeset).Tests and linting
pnpm testand lint the project withpnpm lint