Doubled is updated..you can$inspect it :Preview

Doubled is updated..you can$inspect it :Preview

In that code, it is, but inmy code, it isn't.

4. It seems convenient in some use cases (like the ones they've used in the examples). But I think we absolutely need a way to opt out of that behavior.

1. How will pending state be handled?

The value is the value. The UI may display a previous value in order to maintain consistency, but it wouldn't make sense to have stale values elsewhere such as in event handlers

How do $effects not run until all async $deriveds are updated?

We just... don't run them? I haven't seen the stream so I'm not sure why it should be impossible.

3. About when will this be merged?

No idea! Soon hopefully.

4. Why does async stuff dependent on sync stuff cause sync stuff to not update synchronously in the template?

Because otherwise you'd see things like2 * 2 = 2 and that's insane

5. Why doesn't doubled ever update in this code?

Because you're reading the state inside asetTimeout. There's no way for Svelte to associate the state read with the dependency in that case. Theremight be some way to catch those cases so we can warn on them, but it's probably just a matter of education

6. Should there be arenderAsync function for SSRing async components?

There's an 'Async SSR' section above that addresses this

7. What other libraries/articles/frameworks inspired this?

We researched prior art but didn't see anything we liked to be honest. We reached this design from first principles.

React — as soon as the delay exceeds the update frequency, the app breaks

Devbox not found 😢

Here's anexample of ignoring stale promises

Unfortunately, by manually orchestrating this state machine you lose the advantages of suspense
And even if you createa version that works with suspense, it doesn't work with $effect.pending

Another approach could be to use abort signals (#15845 (reply in thread))

I'm hopeful for the integration of abort signals, I believe it may be the right abstraction

I tried to makemy own integration, but it seems that the proposal is not yet prepared for rejected promises (the app simply crashes and the boundary does not capture any errors)

Edit: The issue was not the rejected promise, but an infinite loop for some reason
I fixed it, but $effect.pending is still broken (in a different way this time)

Here's anexample of ignoring stale promises

@Rich-Harris, It looks like you saved this example over the default example provided at the beginning of the discussion.

Ah whoops! Fixed. Also made the devbox public.

I also added agetAbortSignal function that you can use inside effects and deriveds. It means you cando this sort of thing:

import{getAbortSignal}from'svelte';constresponse=$derived(awaitfetch(`/blah/${foo}`,{signal:getAbortSignal()}));constdata=$derived(awaitresponse.json());

Ah whoops! Fixed

Now it is a broken version of the getAbortSignal demo 😁
I loved the working version tho

dammit! fixed again. not sure whybranch-async doesn't includegetAbortSignal

I would assume that you should wrap apples and bananas in a<svelte:boundary> with afailed snippet.https://svelte.dev/docs/svelte/svelte-boundary#Properties-failed

<svelte:bondary><li>apples {awaitgetPrice('apple')} each</li><li>bananas {awaitgetPrice('banana')} each</li>{#snippetfailed(error,reset)}whoops, apples or bananas failed.{/snippet}</svelte:boundary><li>canteloupes {awaitgetPrice('canteloupe')} each</li>

Exactly — just the same as if there was noawait andgetPrice was a synchronous function that threw an error

thanks!

Ok. ButcreateAsync isn't part of Solid, it's part of Solid Router; the Solid docs and tutorials steer people towardscreateResource so that's what we're talking about here, regardless of how things may look in 2.0.

The approach has its merits though I'm not personally sold on the programming model

I'm not personally sold on the programming model

What is "programming model" in that case?

Nothing in the currentcreateAsync is tied to the Router or 2.0.

It's not in core as we're focusing on the next major.
The import path/package really isn't relevant here.

More features will be included once 2.0 lands, but these aren't implemented nor restrict the currentcreateAsync.

@madaxen86 Currently Solid'screateAsync(current version)/createResource aren't noticeably different from each other.. Same non-blocking, parallel fetching, auto-serializing, auto-streaming, async SSR etc...createAsync was introduced to streamline the API to make it more composable (useful for interacting with Solid Router'squery andaction APIs), butcreateResource has had those capabilities for the past 6 years.

There are 2 shortcomings of the approach. Neither of them related to performance or architecture but to ergonomics.

First, our async isn't completely colorless in the sense that async values can be null, so people need to null check stuff is there until it is even with mechanisms like Suspense. So while you don't have to worry about passing promises around or the whole "where you fetch" dilemma client (non-RSC) uses of data-loading with Suspense have with React you introduce nullability into the tree.

The second is Suspense being too eager to bail out. It is really easy to trigger Suspense on some small async update on the page causing return to fallback. Using Transitions is one way to avoid this, but most of the time people would probably rather just tear. This has lead to stuff likeuseDeferredValue in React and.latest on our resources. The truth is 99% of people will never knowingly use Transitions. They are mostly there for things like Routing. The cases that Rich refers to in the forking section. So they aren't generally part of the experience of developing. However aggressive Suspense bailout can get people there much earlier than they intend.

Of course, sitting with these issues over the years these are things we are already working on remedying in the next major version. But it is worth noting the proposal above for Svelte doesn't have these issues. The async holding along the graph +$effect.pending() removes the need for aggressive Suspense(boundary) bailout, and the compiled use ofawait plus the same holding removes the non-nullability. With this foundation the other async adjacent features should layer on quite nicely. This is very exciting progress in this area.

@ryansolid happy to see you here! Thanks for reading the proposal.

What is "programming model" in that case?

Just the fact that I'm not dealing with promises in a way that feels JavaScript-native, but rather via a framework's abstraction. I totally understand why it is the way it is, and it's very much a matter of taste, but I don't think it would be the right design for Svelte. Ido like how aggressivelycreateAsync/createResource discourage waterfalls; in the worst case our design trades off a little performance for ergonomics here (though on the flip side it means that people are encouraged to learn patterns and techniques for avoiding waterfalls that apply toall their code, not just their components).

The 'JavaScript-native' thing is obviously a minefield. Svelte is transforming your async code and doing all sorts of behind-the-scenes scheduling, but React and (IIUC) Solid are throwing to trigger Suspense; to me these feel equivalently magical. YMMV!

return await db.user.create(user);

Is theawait ideal here?

It's an unnecessary extra microtask but I find it conceptually clearer. YMMV

@hmans we're exploring the RPC space (@dummdidumm in particular is deep in this rabbit hole at present)

Anywhere we could follow along? Would be an immense timesaver to have an integrated RPC in sveltekit.

I LOVE THIS - is there a branch or place for discussion ?

THIS IS SO CLEAN! Taking it one step further to have Tanstack query-like destructuring of the data, loading, error, would be chef's kiss.

Right, so if e.g.page.url andpage.params etc change, then everything derived from them (await loadStuff(page.params.stuff)) will update at the same time, wherever they appear in the app. But if you have something that doesn't depend on those things (like{time.now} or{mouse.x}x{mouse.y}) then it will update immediately. I assume that's the desired behaviour?

Yeah, I had hoped thattime.now wouldn't change so long asawait loadStuff() is still pending

Why?

100% agree, i think the fact that$derived() accepts an expression should be leveraged. I was just giving concrete examples of some alternatives since that tends to help me when looking at decisions like this. i hadn't actually though through the pitfalls of$derived.async(...);. Then having to statically analyzeconst output = await $derived.by(…) has some very clear pitfalls. like what does

constfooPromise=$derived.by(…)//.. several lines of codeconstfoo=awaitfooPromise;

do, this would be very easy for someone to do as a refracting and completely break how something works without being clear why it broke.

Should of included the pitfalls directly in the initial message i was pre-coffee :)

Looking forward to this shipping, if this works as promised its going to be amazing.

wait, am I supposed to dolet x = await $derived(...) orlet x = $derived(await ...)?

Could the compiler allow both? Evenawait $derived(await ...), while useless, could be valid async svelte code

Evenawait $derived(await ...), while useless

useless AND nightmarish

Exactly this. You can't use await outside an async function, but if you pass an async function to $derived.by then the value will be a promise

@Rich-Harris I still don't understand this. Why wouldn't something likethis work:

declarefunction$derivedBy<T>(func:()=>T):Awaited<T>// the type of this is number, not Promise<number>letnum=$derivedBy(async()=>await5)

...and the compiler can just treat it as if it were written like this instead:

asyncfunctionderivedTemp(){returnawait5}letnum=$derived(awaitderivedTemp())

And, to avoid a breaking change, a new name (e.g.$derived.byAsync or$derived.byAwait) can be used.

Update: I just realised this can also be implemented in user-land, using an IIFE:

letnum=$derived(await(async()=>{await5})())

But, IMO this is not ideal. And, if it, or the workaround using regular functions, defeat the purpose of$derived.byAsync, then the purpose of$derived.by is also defeated by the same concepts (without async), yet it exists.

I explained it above#15845 (reply in thread)

We actually implemented this exact thing a while back (as an import rather than a rune, but same semantics) but decided not to land it because your console quickly fills up with DOMExceptions that you can't really get rid of (unless you store a reference to the promise returned fromfetch and attach a floating noopcatch handler).

But with async stuff it does potentially become more valuable, so it might be worth revisiting

I wanted to up vote revisit the abort signal, I watched that PR and was really looking forward to it.

Great question. The short answer is yes, if you press 'clear' then theinput won't clear until the results have come in. In that case you would need to express that intent ('clear the input as well as resetting the value')programmatically:

<buttononclick={()=>name=input.value=''}>clear</button>

As for custom inputs, it works by checking if the current element isdocument.activeElement. It's entirely possible that this will break for web components, because there is no limit to how much sadness they can cause.

There are many use cases where we want to respond instantly to user input and fetch something in background. So, we definitely need a way to control that since both behaviors are useful.

Maybe for opt in:

lettext=$state.deferred("");letresults=$derived(awaitsearch(text));

Other options.lazy.

Or for opt out:

lettext=$state.eager("");letresults=$derived(awaitsearch(text));

Other options.immediate,.instant.

Another idea, syncing only between the parts of the UI that have the same closest parent boundary (or possibly another special element), for example:

<script>import {delayed }from'./utils.js';let x=$state(0);</script><svelte:boundary><inputtype="range"bind:value={x} /> <span>{x}</span><svelte:boundary><inputtype="range"value={awaitdelayed(x)}disabled />        <span>{x}</span>{#snippetpending()}<p>loading...</p>{/snippet}</svelte:boundary></svelte:boundary>

The outsideinput andspan would get updated immediately after the user interacts, while the inner ones update only afterdelayed resolves. On the surface, the way it works feels kinda intuitive, but I'm not sure if it's the best solution.

That was one of our first designs. Long story short it leads you into impossible-to-resolve situations

Looks like a new bug, will investigate

Is this another bug? Seems like$effect.pending() isn't changing to false:https://svelte.dev/playground/5c76337c47a1413f8b86f148bb97a553?version=pr-15844

Yeah there are bugs around$effect.pending()

https://svelte.dev/playground/767e0bfd75614664a41ba73f28cc424c?version=pr-15844

For me, simply double-clicking oncount desyncs it.

Thanks for the test cases — these are all now fixed

If you look at the JS Output tab of theplayground and switch toserver mode you'll see what happens — we literally ignore everything except thepending snippet:

In other words for now everything starts in the browser. Obviously that's not tenable in the long term; we want to be able to pass promises from the server to the client.

It's not straightforward though. Consider a case like this:

<script>if (browser) {constx=$derived(awaitfoo());consty=$derived(awaitfoo());// ...  }else {constz=$derived(awaitbaz());  }</script>

Where does the serialized data 'go'? If we somehow bake the values into a comment that the component reads as it hydrates, then it will expect two payloads but we've only baked in one. And it's not even one that we want to use!

Or this:

<script>import {blah }from'./stuff';importChildfrom'./Child.svelte';</script><Childblah={awaitblah} />

<script>import {blah }from'./stuff';let props=$props();</script><p>{props.blah===awaitblah}</p>

This needs to render<p>true</p> regardless of what type of valueblah resolves to, so we can't just serialize the data in isolation for each component; we would need to have some central registry that every component can refer to. Something like this, perhaps:

const{ head, body, data}=awaitrenderAsync(App,{...});return`<!doctype html><html>  <head>    <meta charset="utf-8">    {head}  </head>  <body>    <div>${body}</div>    <script type="module">      import { hydrate } from 'svelte';      import App from './App.svelte';      hydrate(App, {        target: document.querySelector('#target'),        data:${serialize(data)}      });    </script>  </body></html>`;

(I'm glossing over a lot of stuff but you get the idea.)

Alternatively, Svelte could delegate it to frameworks like SvelteKit which could provide their own abstractions (fetch caching, RPC utilities etc) and if a given expression doesn't have pre-rendered data ready to hydrate,hydrate could simply wait until the client can fix the gaps before returning.

Shorter version: there's a lot of stuff to figure out here and we don't yet know what it'll look like, but it's very much on the radar.

I'm enough of a purist that I struggle a bit with the idea of handling errors by shoving a<meta> tag that indicates an error inside a 200 response. It'sprobably fine, but I don't feel confident that it will work reliably everywhere (like, what if the page has a cache header likes-maxage — can you stop your CDN from caching it?)

Instead, I quite like the idea of separating critical stuff (status code,<head>, some of the<body>) from non-critical stuff — perhaps something like this:

response.write(`<!doctype html><html><head>`);try{// `stream` returns `Promise<{ head: string, body: AsyncIterator<string> }>`const{ head, body}=awaitstream(App,{...});constresponse=newStreamedResponse(200);response.write(head);response.write(`</head><body><div>`);asyncfunctionnext(){const{ value, done}=awaitbody.next();if(done){response.write(`</div><script>${HYDRATE}</script></body></html`);}else{response.write(value);next();}}next();returnresponse;}catch(error){returnnewResponse(getStatusCode(error),renderErrorPage(error));}

We could demarcate non-critical content with an attribute on<svelte:boundary>:

<script>import {page }from'$app/state';import {getPost }from'$lib/api';constpost=$derived(awaitgetPost(page.params.slug));</script><!-- critical --><svelte:head>  <title>{post.title}</title></svelte:head><h1>{post.title}</h1><divclass="post">{@htmlpost.content}</div><!-- non-critical --><svelte:boundarystreamable>  <Comments />  {#snippetfailed())<!--ifanerroroccurswhilerenderingcomments,thissnippetgetsincludedintheserver-renderedHTML-->  {/snippet}</svelte:boundary>

Inside a streamable boundary, certain restrictions could apply, like no<svelte:head>. Anyway, just spitballing at this stage. (Not pictured: a way of capturing the error during SSR so that you can log it, or fail if prerendering.)

Yeah I like it! I can't think of a better way. If you want to stream something critical it just comes with the caveat that it might error and still send a 200. So best practice remains to only stream non-critical content.

For a client side navigation this wouldn't matter as much right? Everything could just be streamed as it resolves?

Ah yep, the example wasmeant to show immediate writing of critical content but I wrote it wrong 😆

For client-side nav yeah, I think you could stream everything

Awesome! This is going to be great

Hey! In principle the door is open on our side too. In practice it may prove tricky, because the proposal we're about to share (this week or next) integrates with the rest of SvelteKit in a way that might be difficult to do in a less opinionated library. For example aquery in our design isn't just a wrapper around an HTTP transport mechanism, it also works with our reactivity system to manage a local cache, and has a mechanism for optimistic updates. (Meanwhile acommand causes currently active queries to clear their cache and re-run, unless you explicitly refresh queries in a more granular fashion.)

We also have form functions that are very specific to Svelte, and prerender functions that are very specific to SvelteKit. All of this works with SvelteKit's (de)serialization mechanism which allows everythingdevalue allows, plus anything you've defined in your owntransport hooks, plus nested Promises, plus (soon, hopefully) streams and async iterables. And we'll likely have some opinionated handling of version skew.

So there are likely too many implementation details that can't really be outsourced — the coupling of the different pieces within the frameworkis the real value. What's left is the transport mechanism, which as you say is relatively straightforward (though it admittedly becomes slightly less so when you factor in batching and real-time).

I think what probably makes sense is for us to build this within SvelteKit to begin with, and then once we ship something we can start to get a sense of which pieces could become part of a common base.

Seems like a good plan! And I agree: I also ain't sure whether/how a full-fledged RFC infrastructure can be made agnostic. Looking forward to your RFC!