fix: allow async {@const}
in more places
await doesn't work when used in conjunction with @const
await isn't allowed in non-async function (Note that you need plugins to import files that are not JavaScript)
Using Svelte compiler version 5.36.12
running Svelte compiler version 5.36.12
blocking an upgrade
Implemented by reusing the async_body
function inside Fragment.js
. Also removes the ability to reference a {@const ...}
of an implicit child inside a boundary pending/failed snippet:
Implemented via / only taking effect with the experimental flag so the behavior change only applies there as this is a breaking change strictly speaking. Also added a compiler error for this.
closes #16462
feat:
, fix:
, chore:
, or docs:
.packages/svelte/src
, add a changeset (npx changeset
).pnpm test
and lint the project with pnpm lint
Latest commit: d41d821
The changes in this PR will be included in the next version bump.
Name | Type |
---|---|
svelte | Patch |
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
pnpm add https://pkg.pr.new/svelte@16643
I had the same issue, and this PR fixed it for me.
As in #16571, the value of $effect.pending()
is stuck at a non-zero value after the initial promise has been resolved. For subsequent promises inside the boundary the counter works fine. Is this the intended behavior?
See Playground
Implemented by reusing the async_body
function inside Fragment.js
. Also removes the ability to reference a {@const ...}
of an implicit child inside a boundary pending/failed snippet: - existing duplication of consts can have unintended side effects, e.g. async consts would unexpectedly called multiple times - what if a const is the reason for the failure of a boundary, but is then referenced in the failed snippet? - what if an async const is referenced in a pending snippet? deadlock - inconsistent with how it behaves for components where this already does not work Implemented via the experimental flag so the behavior change only applies there as this is a breaking change strictly speaking. Also added a compiler error for this. closes #16462