async: easier way to boundary the same component that needs async data

[ottomated]

Describe the problem

While exploring the async branch, I commonly wanted a component something like this:

<!--- Post.svelte -->
<script>
  const post = await getPost();
</script>

<h1>{post.title}</h1>
<!-- etc... -->

However, now I need a <svelte:boundary> in every parent component (assuming I don't want one at the root layout, to minimize the amount of pending state).

Describe the proposed solution

Maybe some way to say "always wrap this component in a boundary"?

<svelte:options boundary={true} />
<script>
  const post = await getPost();
</script>

{#snippet pending()}
  loading post...
{/snippet}

<h1>{post.title}</h1>
<!-- etc... -->

Or, a boundary at the root of a component encapsulates its script block?

<script>
  // This is treated as being inside the boundary below
  const post = await getPost();
</script>
<svelte:boundary>
  {#snippet pending()}
    loading post...
  {/snippet}

  <h1>{post.title}</h1>
  <!-- etc... -->
</svelte:boundary>

Importance

would make my life easier

[paoloricciuti]

The boundary limitation will likely be lifted in the future so not sure if this would be useful...also you would need to pass the pending snippet somehow no?

[ottomated]

The boundary limitation will likely be lifted in the future

I hope so, but even without the requirement I think this would be useful for the cases where you want a boundary. It doesn't make sense to me to have the error handling and loading state forced to be in a wrapper component

also you would need to pass the pending snippet somehow no?

In my example I proposed how the pending snippet could be defined

[paoloricciuti]

In my example I proposed how the pending snippet could be defined

lol how did I miss this? I shouldn't answer issues before coffee ☕

[Thiagolino8]

lol how did I miss this? I shouldn't answer issues before coffee ☕

His suggestion is that if svelte:options has the boundary option, the snippet declared at the top-level should be used

A less magical option would be to accept an object instead of a boolean

<svelte:options boundary={{pending, failed}} />
<script>
  const post = await getPost();
</script>

{#snippet pending()}
  loading post...
{/snippet}

{#snippet failed(e)}
  {e.message}
{/snippet}

<h1>{post.title}</h1>
<!-- etc... -->

But an even simpler solution (which already works today) is to not wait for the promise in the script

<script>
  const post = getPost();
</script>

<svelte:boundary>
  {#snippet pending()}
    loading post...
  {/snippet}

  {#snippet failed(e)}
    {e.message}
  {/snippet}

  <h1>{(await post).title}</h1>
</svelte:boundary>
<!-- etc... -->

[realfakenerd]

What if we do this?

<script boundary="{{pending, failed}}">
  const post = await getPost();
</script>

// or simply

<script boundary>
  const post = await getPost();
</script>

We already have the module, generics and lang. If possible and good for DX, why not other atribute for the script?

[ottomated]

But an even simpler solution (which already works today) is to not wait for the promise in the script

Yeah but this is annoying when you have to use the result of the promise for more than one thing.

[Rich-Harris]

Well, you have @const for that (and we plan to allow arbitrary declarations inside markup to alleviate some of the weirdness around @const, though that's a separate convo we weren't planning to get into until the async branch settled down).

If boundaries are optional (because of async SSR) and you can declare stuff inside boundaries if you need to use it multiple times, then I don't see any reason to introduce a second way to create boundaries. None of the ideas presented here really stand up to scrutiny — using <svelte:options> alongside top-level snippets creates a footgun because suddenly you can't use script-level declarations inside the snippets (as that would make them non-hoistable); if you need to add on onerror callback you need to refactor everything; a top-level <svelte:boundary> wrapping the <script> is equally confusing from a lexical scoping perspective but causes additional confusion as soon as you have more than one of them.

It's just really not worth it! We explored this stuff when we were first designing error boundaries and quickly concluded it would be a bad idea.

[realfakenerd]

... using <svelte:options> alongside top-level snippets creates a footgun because suddenly you can't use script-level declarations inside the snippets (as that would make them non-hoistable) ...

@Rich-Harris i thought on something like this:

<script async>
  const foo = await bar();
</script>

I don't know what problems it could cause for you and the team that code the Svelte to do it that way, but it looks nice and easy to understand, better than wrapping everything inside an <svelte:boundary>, what do you think of this?

[Rich-Harris]

When it's possible to use await outside a boundary, you won't need an opt-in mechanism, unless you want to provide pending and failed UI which that proposal doesn't account for. Either way it makes no sense!

[ottomated]

we plan to allow arbitrary declarations inside markup

I think this would alleviate most of the issues. My use-case where @const doesn't cut it is somewhat like this:

<script>
  let open = $state(false);
  const cart_promise = get_cart();
  if (page.url.searchParams.has('cart')) {
    await cart_promise;
    open = true;
  }
  const cart = $derived(cart_promise.current);
</script>

so if that is possible within markup I would be satisfied.