Post

We shipped this just now, in SvelteKit 2.20. Having AsyncLocalStorage available ~everywhere makes it possible to create some really nice abstractions — we have a bunch of ideas for other stuff we can do. Look forward to seeing how you all use it: svelte.dev/docs/kit/loa... bsky.app/profile/svel...

svelte.devLoading data • Docs • SvelteLoading data • Svelte documentation

10 reposts111 likes

Before the update I had to pass a Cloudflare R2 binding down to a helper function that I then had to attach to `locals` for uploading an image - but now I can cleanly separate that and just have an `uploadImage()` function I can use anywhere. This is GREAT for Cloudflare bindings.

It'll still work in a lot of cases — if you call it synchronously then it'll retrieve the context without the need for ALS. it's only if you await something first that it'll blow up in StackBlitz

For the uninitiated, AsyncLocalStorage is a Node API (nodejs.org/api/async_co...) that's been adopted by other server runtimes. But we really need it in the browser too, and that's where github.com/tc39/proposa... comes in. Really hoping it moves forward, it will be huge

github.comGitHub - tc39/proposal-async-context: Async Context for JavaScriptAsync Context for JavaScript. Contribute to tc39/proposal-async-context development by creating an account on GitHub.

I'm hoping making it a standard will also have positive influence on eliminating edge cases. There's still tiny gaps of coverage where the context can get lost and the closer to the JS engine the implementation lives the better

It being a standard makes custom implementations of async libraries that do pooling/shenanigans more likely to care about instrumenting to maintain async context or at least make conscious decisions about its behavior instead of leaving it to chance or producing undefined, undocumented behavior