Repository navigation
fix: batch views of reactions - #19030
dummdidumm wants to merge 13 commits into
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/svelte/c/7e395a152fc55123d78f31d49b2b8871472da8edOpen in |
🦋 Changeset detectedLatest commit: 7e395a1 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 |
| if ((onscreen.f & EFFECT_OFFSCREEN) !== 0) { | ||
| onscreen.f ^= EFFECT_OFFSCREEN; | ||
| } |
There was a problem hiding this comment.
minor thing but we have a mix of styles in the codebase, should we standardise on the one-liner? i think it's probably more efficient anyway — a bitwise comparison plus a numeric comparison, then if the condition is true another bitwise operation and an assignment, versus two bitwise operations and an assignment
| if ((onscreen.f & EFFECT_OFFSCREEN) !== 0) { | |
| onscreen.f ^= EFFECT_OFFSCREEN; | |
| } | |
| onscreen.f &= ~EFFECT_OFFSCREEN; |
(unless the assignment is the costly part, i guess?)
|
|
||
| /** | ||
| * The run of `reaction` that applies in the active view of the world: the record of a block or async | ||
| * effect in the active batch, if it has one (see `update_record`), or else the reaction itself — whose |
There was a problem hiding this comment.
| * effect in the active batch, if it has one (see `update_record`), or else the reaction itself — whose | |
| * effect in the active batch, if it has one (see {@link update_record}), or else the reaction itself — whose |
| * If it is MAYBE_DIRTY, will set the status to CLEAN | ||
| * If it is MAYBE_DIRTY, will set the status to CLEAN. | ||
| * Deriveds are only checked like this in the real world — within the view of a batch, | ||
| * see `view_entry`. Effects are checked against the run that applies (see `run_of`). |
There was a problem hiding this comment.
| * see `view_entry`. Effects are checked against the run that applies (see `run_of`). | |
| * see {@link view_entry}. Effects are checked against the run that applies (see {@link run_of}). |
|
|
||
| /** | ||
| * True while the batch commits, i.e. while it updates the DOM and runs effects. | ||
| * Effects that run then do so for the real world |
There was a problem hiding this comment.
is this right? if A and B are in-flight and A commits, don't effects run in A's world?
|
|
||
| /** | ||
| * Effects to (re-)validate when this batch is processed next, and their status (DIRTY or MAYBE_DIRTY): | ||
| * those that were scheduled while it wasn't being processed (see `schedule`), and those whose run |
There was a problem hiding this comment.
sadly we can't do this for private methods (i.e. #defer_effects on the next line) but we can at least make this cmd-clickable
| * those that were scheduled while it wasn't being processed (see `schedule`), and those whose run | |
| * those that were scheduled while it wasn't being processed (see {@link schedule}), and those whose run |
| * so they can be rescheduled if the branch survives. | ||
| * @type {Map<Effect, { d: Effect[], m: Effect[] }>} | ||
| * Branches that still exist, but will be destroyed when this batch | ||
| * is committed — we skip over these during `process` |
There was a problem hiding this comment.
| * is committed — we skip over these during `process` | |
| * is committed — we skip over these during `#process` |
| // pending work inside a skipped branch doesn't block, the branch is going to be destroyed | ||
| if (!this.#is_skipped(effect)) { | ||
| return true; | ||
| } | ||
| } |
There was a problem hiding this comment.
good candidate for merging into main independently
…ause testing special cases of pt1, but commit for now either way because good for comparison)
This branch has not been deployed
2 participants
This changes the async reactivity system when multiple batches are active such that they check if they need to be re-executed in a batch by comparing the write versions of the dependencies they last saw with the ones they have now - if there's any difference, they re-execute. These write version arrays, the value, the dependencies that batch sees - all is stored in a record local to the batch. Logic exists to promote them to the real world if we know the derived was computed from real-world/latest dependencies only, and async/block effects promote once the batch commits.
This introduces some complexity, on the other hand various things are simplified or removed (
#commitfor example got easier).This is WIP, but I've commited a readme that gives a good overview of how the system works in more detail and the gaps vs
async-reactivity-another-try-pt-1