* feat: type `currentTarget` in `on` function
* `EventTarget &` is redundant, `Element` already extends `EventTarget`
* no need for optional chaining
* add currentTarget for other overloads
* update changeset
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* fix: prevent infinite loop when HMRing a component with an `await`
* update test
* fix
* reintroduce old logic to fix ever-growing stack of block effects
* update snapshot
* tweak names for clarity, simplify `update` slightly
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
* fix: set Root start/end to null when fragment contains only whitespace
* format
* always set root.start to 0 and root.end to template.length
* Update .changeset/fruity-knives-ring.md
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Co-authored-by: Rich Harris <hello@rich-harris.dev>
In #17105 one line in `update_reaction` was changed that can cause reactivity loss. It checks if the reaction is updated inside of an effect and only then will push to the reactions. The prior version had an additional check to still add to the reactions if there is already at least one reaction on the derived, indicating it is connected. Removing this check fixes#17263 while keeping correctness: a connected derived by definition at least has one reaction and therefore can properly cleanup.
* fix: link offscreen items and last effect in each block correctly
It's possible that due to how new elements are inserted into the array that `effect.last` is wrong. We need to ensure it is really the last item to keep items properly connected to the graph. In addition we link offscreen items after all onscreen items, to ensure they don't have wrong pointers.
Fixes#17201
* revert #17244
* add test
* use local version of esrap, for now
* WIP
* WIP
* fixes
* more
* add `Declaration` visitor
* add `TransitionDirective`
* `UseDirective`, `OnDirective`
* more directives
* `SpreadAttribute`, directive shorthands
* `{#if ...} {:else ...}`
* fix
* more
* add tags, `AnimateDirective`
* `KeyBlock`
* `SelectorList`, `<svelte:whatever />`
* quote text in `Attribute` visitor
* tweak test logic to reduce false negatives
* fix
* fix
* add separate test suite
* fix
* more
* slightly nicer printing
* install from pkg.pr.new
* merge main
* bump
* fix
* remove any
* fix indentation
* replace TODO with a type error
* bump
* fix
* esrap@2
* lockfile
* try this
* regenerate
* add small comment
* fix test file
* ensure new lines at end of file
* common tests
* tests for A-nodes
* fix interface
* tests for B-nodes
* delete basic test
* tests for C-nodes
* combine css tests
* tests for E-nodes
* tests for H-nodes
* tests for I-nodes
* tests for K-nodes
* tests for L-nodes
* tests for N-nodes
* add todo
* remove other todo
* tests for O-nodes
* tests for P-nodes
* tests for R-nodes
* tests for S-nodes
* tests for T-nodes
* tests for U-nodes
* seperate css and svelte visitors for clarity
* fix failing test
* rename early tests
* fix const test
* fix svelte-element
* move block to css visitors
* fix css output
* fix #if indentation
* fix self closing tag problems
* use common method for attributes
* put attributes into multiple lines if too long
* fix new lines for #each:else
* fix svelte element new lines
* rmeove usless comments & fix playground
* improved formatting
* support formatting for a lot more nodes
* style
* fixes for formatting
* cleanup
* make typescript happy
* add formatting related test
* add docs
* changeset
* regenerate types
* fix self-closing tags
* fix bracket placement
* break length 50
* add support for additional comments
* remove abstract keyword
* strip out more typescript gubbins
---------
Co-authored-by: ComputerGuy <63362464+Ocean-OS@users.noreply.github.com>
Co-authored-by: Manuel Serret <mserret99@gmail.com>
Fixes#17236
* fix: generate correct code for simple destructurings
* add a test (existing one doesn't fail on main)
* adjust existing test so it fails on main
* slightly neater approach (with identical outcome)
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
This ensures that an animation does not run when the element is first transitioning in. Else the animation would mess with the transition (overriding its animation basically). Due to our test setup it's not testable but I veryfied it fixes#17181 (tested all reproductions in there)
It's possible that due to how new elements are inserted into the array that `effect.last` is wrong. We need to ensure it is really the last item to keep items properly connected to the graph.
Fixes#17201
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
Since async-await was introduced into the code base a lot has changed. This lifts the restriction.
Closes#17131 (though I still wonder why Skeleton does that)
We have to take non-tracking contexts into account, especially while in the original `fork(() => ...)` context.
Closes#17206
---------
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
* fix: don't execute attachments and attribute effects eagerly
attributes_effect and attachments are blocks since they need the managed "don't just destroy children effects"-behavior, but they're not block effects in the sense of "run them eagerly while traversing the effect tree or while flushing effects". Since the latter was the case until now, it meant that forks could cause visible UI updates.
This PR introduces a new flag to fix that. `BLOCK_NON_EAGER` is basically a combination of block effects (with respects to the managed behavior) and render effects (with respects to the execution timing).
Fixes https://github.com/sveltejs/kit/issues/14931
* managed_effect
* fix: take async into account for bindings/transitions/animations/attachments
- block on async work
- error at compile time on await expressions. Right now it gives confusing errors later at compile time or at runtime
Fixes#17194
* this was weird
* fix: maintain correct linked list of effects when updating each blocks
* working
* tidy up
* changeset
* remove unnecessary assignment, add comment explaining unidirectionality
* fix: don't cancel transition of already outroing elements
#16977 forgot one detail: While an element is outroing, the block of e.g. an if block can be triggered again, resolving to the same condition. In that case we have an in-between state where the element is still onscreen but already outroing. We have to detect this to not eagerly destroy the corresponding effect when we arrive at the outro/destroy logic.
Fixes#16982
* fix
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* perf: don't use tracing overeager during dev
#17176 is a case where many sources are created and then written to (due to Svelte 4 prop mechanics), and our tracing kicked in eagerly. That combined with the excessive depth of the related stack traces slowed things down tremendously.
The fix is simple: Don't record stack traces until we've seen this source get updated for a couple of times. Additionally we now delete the `updates` map after a flush. Previously it was just an ever-growing stack trace map.
* fix
* fix
* fix: avoid other batches running with queued root effects of main batch
When `#traverse_effect_tree` runs, it can execute block effects, which in turn can create effects which are scheduled, which means `queued_root_effects` is now filled again. We didn't take that into account and assumed that in `#commit` we would have no queued root effects. As a result another batch could wrongfully run with the queued root effects of the main batch. That in turn can mean that `skipped_effects` is different on the other batch, leading to some branches not getting traversed into. As a result part of the tree is marked clean while further below batches are still not marked clean. That then breaks reactivity as soon as you schedule an effect in this still-not-clean sub tree, as it will not bubble all the way up to the root, since it comes across a not-clean branch, assuming something was already scheduled.
The fix is simple: Stash the queued root effects before rebasing branches.
Fixes#17118
* add note to self
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Execution of eager effects didn't set `is_updating_effect`, which meant the logic in `get` would wrongfully prevent dependencies being added to `reactions` of sources/deriveds.
Fixes#17133
* fix: correctly handle functions when determining async blockers
We didn't properly handle functions (function declarations/expressions/arrow functions) when calculating what is a blocker. More specifically
- we did defer assignment of variable declarations even for arrow functions and function expressions, which is unnecessary and causes bugs when they're then referenced eagerly further below
- we did not compute blockers for functions. They could reference blockers themselves, as such other code referencing them should wait on the related blockers
Fixes#17129
* put into its own function
* fix: take blockers into account when creating `#await` blocks
The unrelated-but-in-the-same-issue-referenced-bug
* oops
* fix
* minimize compiled output changes
* no idea why editor showed these as unused
Use case: Remote queries that are created on one screen, then are used again on another screen. Original parent effect is destroyed in that case but derived should still be reactive. It wasn't prior to this fix because inside `get` the `destroyed` variable would be true and so deps would not properly be recorded.
Fixes https://github.com/sveltejs/kit/issues/14814
* fix: parallelize async `@const`s in the template
This fixes#17075 by solving the TODO of #17038 to add out of order rendering for async `@const` declarations in the template.
It's implemented by a new field on the component state which is set as soon as we come across an async const. All async const declarations and those after it will be added to that field, and the existing blockers mechanism is then used to line up the async work correctly. After processing a fragment a `run` command is created from the collected consts.
* fix
* tweak
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
#17061 didn't properly handle the case where the title is sync but reactive and async work outside is pending. Handle this by creating a proper effect for the document title, and make sure to wait on it and flush it once ready.
Fixes#17114
There's a possibility of a race condition where `batch.deactivate()` is called while `current_batch !== batch`, and so it would deactivate another batch, which can lead to zombie batches that are never flushed, subsequently leading to wrong `batch_values`. This fixes that by checking if the current batch is the own batch.
Fixes#17109
* fix: wait on dependencies of async bindings
Correctly takes into account blockers for bindings. Also ensures it works for functional bindings.
During that I also noticed a bug in our `nodes_end` assignment logic, which the added test also regresses against.
Fixes#17092Fixes#17090
* ensure async static props/attributes are awaited
* wait on blockers in binding validation
* await dependencies of style directives
* tidy
Fixes#17024Fixes#17049 (comment) (and therefore everything that was still buggy in that issue I think)
* chore: remove unowned check when calling `e.effect_in_unowned_derived`
* WIP
* all non-unit tests passing
* tidy
* WIP
* WIP
* WIP
* note to self
* fix
* fix
* hmm maybe not
* try this
* simplify
* remove skip_reaction
* docs
* add changeset, in case this results in changed behaviour
* Update packages/svelte/src/internal/client/reactivity/effects.js
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
* fix#17024
* fix comment
* revert
* fix
* dry
* changeset
* fix WAS_MARKED logic
* failing test (that uncovered other unrelated bug) + fix
* fix: delete from batch_values on updates (#17115)
* fix: delete from batch_values on updates
This fixes a bug where a derived would still show its old value even after it was indirectly updated again within the same batch. This can for example happen by reading a derived on an effect, then writing to a source in that same effect that makes the derived update, and then read the derived value in a sibling effect - it still shows the old value without the fix.
The fix is to _delete_ the value from batch_values, as it's now the newest value across all batches. In order to not prevent breakage on other batches we have to leave the status of deriveds as-is, i.e. within is_dirty and update_derived we cannot update its status. That might be a bit more inefficient as you now have to traverse the graph for each `get` of that derived (it's a bit like they are all disconnected) but we can always optimize that later if need be.
Another advantage of this fix is that we can get rid of duplicate logic we had to add about unmarking and reconnecting deriveds, because that logic was only needed for the case where deriveds are read after they are updated, which now no longer hits that if-branch
* keep derived cache, but clear it in mark_reactions (#17116)
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Simon Holthausen <simon.holthausen@vercel.com>
Not all batches will flush right after being activated, some will be activated and then `get` is called on a signal. In that case the value was wrong because we did not apply the changes of that batch. By doing `this.apply()` during `activate()` we ensure we do, which fixes (among other things, likely) a forking bug where old values where sneaking in.
Fixes#17079
* fix: change title only after any pending work has completed
We have to use an effect - not a render effect - for updating the title, and always. That way we change the title only after any pending work has completed.
Fixes#17060
* fix
#16977 had one slight regression which might contribute to #16990: The batch from earlier was restored, but that doesn't make sense in this situations since this has nothing to do with our new async logic of batches suspending until pending work is done. As a result you could end up with a batch being created, and then the restore then instead reverting to an earlier batch that was already done, which means a ghost-batch ends up in the set of batches, subsequently triggering time traveling when it shouldn't. This may help with #16990
No test because basically impossible to do so
Rich Harris
Tee Ming
github-actions[bot]
That Richan
Elliott Johnson
Manuel
Ryan Atkinson
Random Fads
Simon H
adiGuba
ComputerGuy
Paolo Ricciuti