Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: allowawait in components#15844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Rich-Harris merged 674 commits intomainfromasync
Jul 14, 2025
Merged

feat: allowawait in components#15844

Rich-Harris merged 674 commits intomainfromasync
Jul 14, 2025

Conversation

Rich-Harris
Copy link
Member

@Rich-HarrisRich-Harris commentedApr 28, 2025
edited
Loading

This is the PR to go with#15845. Feedback and questions should happen on the discussion rather than here.

Closes#1857,closes#3203,closes#5501

How this works

I'll likely flesh this out in more detail later, but a few quick bullet points:

  • state changes are now scoped to aBatch. This was always implied (we would flush effects in a microtask, if aflushSync didn't get there first, so thata++; b++ would result in one flush rather than two) but now it's explicit
  • Batch has aprocess method that is responsible for callingprocess_effects. Whereas previously this would result in effects running immediately (albeit in two phases, so that e.g.$effect effects happen after other updates), this now only happens for async effects (so that we can know if a state change resulted in async work) and block effects (so that we can know if a newly-created branch has async work, or if newly-destroyed branches can be skipped). All other effects (i.e. user effects, or those that update the DOM) are added to the batch
  • if, after flushing everything, the batch is 'settled', we run the remaining effects. Otherwise, those effects will be scheduled when the batch's async deriveds resolve
  • batches track theprevious values of their sources, so that changes can be momentarily reverted in the case of overlapping batches
  • blocks like{#if ...} etc no longer append or remove branches directly. Instead, they do that in a commit callback belonging to the batch, which runs when everything is settled
  • we introduce the concept of anasync derived, which isn't actually a derived at all — it's a source and an async effect (which is just a normal effect with a flag that letsprocess_effects run it eagerly) in a trenchcoat. This is because deriveds are lazy and would never update in time
  • you create an async derived whenever you have a$derived with anawait expression (that isn't inside a function), or whenever you have anawait expression in a template effect
  • accordingly,$.template_effect now takes a third argument, which is an array of all async deriveds
  • control flow blocks ({#if ...} et al) can also containawait expressions, in which case they are wrapped in an$.async block. These simply pass the async derived to the inner logic, so that the blocks themselves don't need to be aware that they're dealing with async values

I'm sure I'm overlooking a ton of stuff but that's as much braindump as I can give right now. Will add comments to more of the source code as and when I can.

WIP

This is not finished; there are bugs, and parts of the code are a little messy. Some stuff could possibly be extracted into a separate PR so that this one is smaller and more focused (e.g. converting boundaries to theBoundary class).

  • makepreserve_context more accurate
  • extractgetAbortSignal into separate PR?

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 withfeat:,fix:,chore:, ordocs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.
  • If this PR changes code withinpackages/svelte/src, add a changeset (npx changeset).

Tests and linting

  • Run the tests withpnpm test and lint the project withpnpm lint

@changeset-botchangeset-bot
Copy link

🦋 Changeset detected

Latest commit:77e0e60

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
NameType
sveltePatch

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

@svelte-docs-bot
Copy link

@sveltejssveltejs locked and limited conversation to collaboratorsApr 28, 2025
varrestore=capture();
varvalue=awaitpromise;

return()=>{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

is there a reason for this to be curried? from everything i saw it's always called immediately, and it certainly doesn't help minification
example:

letdoubled=$derived(awaitwait(count*2,500));// is compiled toletdoubled=(await$.save($.async_derived(async()=>(await$.save(wait($.get(count)*2,500)))())))();// but without the currying it could beletdoubled=(await$.save($.async_derived(async()=>(await$.save(wait($.get(count)*2,500))))));

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

IIUC there's a microtask-sized gap between anasync function returning and the call being evaluated:

awaitfoo()+bar;//         ^ room here for simultaneous async work to mess with context

The only way to plug that gap is to wrap the whole thing in a call that sets the context and then proceeds to the next expression synchronously. Iam having a bit of a hard time coming up with an isolated example that proves this to be the case, but if you remove theb.call from$.save and$.track_reactivity_loss and remove the thunk wrapper from their return values, you'll see one of the tests fail

(trimmed[0].type==='SvelteFragment'||
trimmed[0].type==='TitleElement'||
(trimmed[0].type==='IfBlock'&&trimmed[0].elseif));
(trimmed[0].type==='SvelteFragment'||trimmed[0].type==='TitleElement');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This reintroduces the many if block anchor comments that we got rid of in#15250 (copy-paste the example with 5 if branches into the async playground and see the difference in the number of comments) - why was it necessary to remove this?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

because my brain wasn't good enough to introduce async logic while keeping that stuff intact

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Alright, my brain is going to implode if I stare at this anymore -- it looks really good!

*@param {Context} context
*/
exportfunctionAwaitExpression(node,context){
letsuspend=context.state.ast_type==='instance'&&context.state.function_depth===1;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

What's the difference between this and the newis_instance field?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

ast_type is part ofAnalysisState,is_instance is part ofClientTransformState. wecould align them if we wanted but i don't think it's important

Rich-Harrisand others added2 commitsJuly 14, 2025 15:48
…s/AwaitExpression.jsCo-authored-by: Elliott Johnson <sejohnson@torchcloudconsulting.com>
@Rich-HarrisRich-Harris merged commit0672e48 intomainJul 14, 2025
15 checks passed
@Rich-HarrisRich-Harris deleted the async branchJuly 14, 2025 19:58
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@dummdidummdummdidummdummdidumm left review comments

@paoloricciutipaoloricciutipaoloricciuti left review comments

@Ocean-OSOcean-OSOcean-OS left review comments

@elliott-with-the-longest-name-on-githubelliott-with-the-longest-name-on-githubelliott-with-the-longest-name-on-github approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Top-level await Svelte suspense (request for comments) Await expressions
5 participants
@Rich-Harris@dummdidumm@paoloricciuti@Ocean-OS@elliott-with-the-longest-name-on-github

[8]ページ先頭

©2009-2025 Movatter.jp