feature request: {#await promise then}

[kamholz]

Is your feature request related to a problem? Please describe.
If you have a promise whose resolve value you don't care about, you can currently do:

{#await promise}
  loading...
{:then}
  resolved
{/await}

but with the shorthand you can't do:

{#await promise then}
  resolved
{/await}

When you don't need to show a loading state, there is no way to omit the variable for the promise's resolve value. This is a fairly common situation, and it would be good to handle it.

Describe the solution you'd like
Support the above syntax where the variable is omitted.

Describe alternatives you've considered
You can work around this by including a variable that you don't use:

{#await promise then done}
  resolved
{/await}

But this is awkward style and may also cause issues with linters.

How important is this feature to you?
Moderate. It's not a show-stopper because there's a workaround, but it also seems like something Svelte should support, and it shouldn't be very difficult.

[furudean]

A thought on the semantics of this, I think {#await promise} would make more sense than {#await promise then}. The then here doesn't have any significance in this case and could be omitted.

[kamholz]

I'm pretty sure we need the then, because without it Svelte would interpret it as when the promise is pending.

[furudean]

I don't think that's the case, the compiler could check for the absence of {:then name} to determine if it's the super-shorthand or not.

[furudean]

I think this covers all the cases? https://svelte.dev/docs#await

[kamholz]

I don't think that's the case, the compiler could check for the absence of {:then name} to determine if it's the super-shorthand or not.

Aside from being overly magical (in my opinion) that isn't sufficient, because then you couldn't show something during loading unless you also wanted to show something after the promise was resolved. Svelte shouldn't impose peculiar restrictions like that.

[kamholz]

I think this covers all the cases? https://svelte.dev/docs#await

Yes, this is not handling any new cases per se. It's just allowing a simpler syntax for an existing case.

[furudean]

Aside from being overly magical (in my opinion) that isn't sufficient, because then you couldn't show something during loading unless you also wanted to show something after the promise was resolved. Svelte shouldn't impose peculiar restrictions like that.

I'm not sure what you mean. Maybe we are misunderstanding each other? I only mean that we can omit the then in this proposed syntax because it doesn't really do anything here. It served as syntax to show which is the output in {#await promise then value}. Here it's just extra. Is that too magical?

Yes, this is not handling any new cases per se. It's just allowing a simpler syntax for an existing case.

That's not what I was referring to, I just mean from a compiler POV it isn't hard to figure out which is which either way.

[kamholz]

I'm not sure what you mean. Maybe we are misunderstanding each other? I only mean that we can omit the then in this proposed syntax because it doesn't really do anything here. It served as syntax to show which is the output in {#await promise then value}. Here it's just extra. Is that too magical?

There are three promise states: pending, resolved, and rejected. {#await} can match all three. In the current syntax, this:

{#await promise}
  loading
{/await}

will match the pending state. With your proposal, there is no clean way to have an {#await} block that only matches a pending state. You'd have to do something like:

{#await promise}
  pending
{:then}
{/await}

So, while your idea does away with the superfluous syntax I'm talking about ({#await promise then done}), it introduces a new one. It also makes the syntax more confusing, because now {#await promise} would sometimes match the pending case and sometimes match the resolved case. My proposal doesn't contain superfluous syntax for any of the cases and you don't have to look beyond the immediate context to interpret what was intended. It also maintains backwards compatibility.

[furudean]

Gotcha. I didn't realize that {#await promise} {/await} was valid syntax in Svelte today. Given that, I think there would have to be a keyword to differentiate it like you describe to not introduce a breaking change.

[aradalvand]

+1 The syntax is straightforward and not problematic, and there would be no breaking change or anything either. So, I'm for this.

[Conduitry]

This syntax is supported now in 3.41.0.