The local state problem can be worked around via wrapping, but this looks like a good idea anyway 👍

{@const count = reactive(0)}
<button onclick={() => count.current += 1}>

export function reactive(initialValue) {
	const value = $state({ current: initialValue });
	return value;
}

Very neat, is the "immediate child" restriction going away?

Probably not, is there a reason you can't declare the variables in your <script> tag?

Probably not, is there a reason you can't declare the variables in your <script> tag?

That was just out of curiosity around the design, now that the feature is growing from useful to convenient.

At this point I would also vote for getting rid of this limitation.

Declarations generally should be close to where they are being used; artificially enforcing more separation does not seem to make much sense. The new design gives a lot of flexibility, keeping this one rule feels quite arbitrary.

It is also not necessarily about top level declarations, e.g. if you have a lot of content/nesting in an #each:

{#each items as item}
  <div class="card">
    <header>
      ...
    </header>
    {const value = ...}
    <p>Value is {value}</p>
  </div>
{/each}

Yeah, you'd be able to use these anywhere, top-level or otherwise

Much needed! Especially because they will just work anywhere in the markup.

Before this I was writing {#if true} {@const value = 1} ... {/if} if I wanted a local variable scope.

(And before {@const} existed I was writing it as {#each [1] as value} ... {/each} 😜)

Will the script tag be necessary after this feature is merged?

{
let count = $state(0);
const increment = () => count++;
}
<button onclick={increment}>{count}</button>

Yes, since for most components there's more to their code than just variables 😄 Also, small nitpick, you can't do multiple declarations in one pair of curly braces. You can do multiple declarators, which is a fancy term for this sort of thing:

{let foo, bar = 0, baz = null} 

Ok, sure. Just out of curiosity, what is the reason for restriction on the type of expressions, statements allowed within the { } boundary?

what is the reason

The template is, well... a template — to turn it into a view you Just Add Water Data. Expressions therein are reactive and (unless you go rogue) side-effect-free. It is the output of the whole process of reactivity. Things update as-needed, in a non-linear order.

Statements on the other hand are the elements of a program. A program runs linearly, top to bottom, then exits. What does this mean in the context of a template? Nothing, really. It's incoherent.

Would awaits inside of these variable declarations behave the same as await elsewhere in the template, avoiding waterfalls?

I'm asking as right now remote functions are fairly painful to use inside of the template outside of trivial cases. Imagine a remote function that takes a bunch of arguments and has many properties that need to be displayed. You end up with something like this:

{#if await getTodo({tenantId: tenant.id, projectId: project.id, todoId: id})}
  <h1>{(await getTodo({tenantId: tenant.id, projectId: project.id, todoId: id})).title}</h1>
  <img src={(await getTodo({tenantId: tenant.id, projectId: project.id, todoId: id})).author.image} />
  <span>Author: {(await getTodo({tenantId: tenant.id, projectId: project.id, todoId: id})).author.name}</span>
  <p>Created at: {(await getTodo({tenantId: tenant.id, projectId: project.id, todoId: id})).createdAt}</p>
{:else}
  Todo not found
{/if}

Right now I'm playing around with creating promises in the script and awaiting in the template but I think {let todo = await ...} has potential to be preferable, at least in some cases.

Not automatically, no — the straightforward implementation of something like this...

{let x = $derived(await one())}
{let y = $derived(await two())}

...would entail creating x then y. (They will update independently after that, but are waterfalled on creation.) #16561 is the issue to watch for that; my hope is that whatever static analysis tricks we come up with to make it possible to update template chunks out of order will also make it possible to de-waterfall things like deriveds

I see. So for someone looking to solve the following combination of problems:

• Avoid waterfalls
• Avoid the verbosity of calling and awaiting the same function each time it's needed in the template
• await inside of a component's boundary (since code inside of the script is outside)

The solution would be a combination of this issue and #16561?

And in the interim it seems like the next closest solution is create the promise inside of script and await it inside of the template each time it's needed. So we still need to await each time, but can avoid the pain and error-proneness of repeating the function call all over the place.

Thanks