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

how about something like a {#scope} or {#local}?

{#scope let a = 123}
{/scope} 

and anything inside the scope (or under same parent) will be able to access the scope.

A very similar thing was discussed in the {@const ...} RFC and as shown, it can get pretty ugly when you have multiple variables.

Hello @Rich-Harris

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.

With regards to this lets looks at the simple example in Solid:

function Counter() {
  return <div>
    {(() => {
      const [count, setCount] = createSignal(0);
      let x = 42;
      console.log("foo", x);
      return <button onClick={() => setCount(count => count + x)}>
        {count()}
      </button>
    })()}
  </div>;
}

This maps 1 to 1 to the imaginary Svelte syntax.

{#snippet counter()}
  <div>
    {@
      let count = $state(0);
      let x = 42;
      console.log("foo", x);
    }
    <button onclick={() => count += x}>
      {count}
    </button>
  </div>
{/snippet}

So what do you mean by "it's incoherent"?

For context , but signals there can't be created in the JS code, they use their own tag-like syntax, that is partly for easier compile-time analysis, there is no really an equivalent of toplevel Svelte <script></script>, basically their constraints are different. which allow you to insert code pretty much anywhere using dollars $, with the caveat that it had a non-signal based model similar to React.

Please support multiple declarations. Maybe something like:

{#script}
  let count = $state(1);
  let double = $derived(count*2);
{/script}

How is

{#script}
  let count = $state(1);
  let double = $derived(count*2);
{/script}

better than

{let count = $state(1)}
{let double = $derived(count*2)}

? It's additional syntax, and it's more typing.

Also @kanashimia

{#snippet counter()}
  <div>
    {let count = $state(0)}
    {const x = 42}
    {console.log("foo", x)} <!-- This is already a thing you can do -->
    <button onclick={() => count += x}>
      {count}
    </button>
  </div>
{/snippet}

You can call functions with void output in the markup. They'll be called each time their dependencies change, which in this example case is only once.

? It's additional syntax, and it's more typing.

Yes, but the syntax is similar to real js syntax except for the wrapping. And actually if you have a lot of variable declarations, a single wrapper is less typing than a pair of curly bracket on every line.

You can do something like

{let foo = 0, bar = 1, baz = 2}

That is just disgusting, though.

Same reason we don't do that in the script tag. Even though this is only a stylistic choice, there's an about it.

You can call functions with void output in the markup. They'll be called each time their dependencies change, which in this example case is only once.

@sillvva Yes, that is true! Although I would consider that more like a hack really. What I had in mind though was more along the lines of untracked context, so console.log(count) won't rerun. Basically a feature to fully subsume toplevel <script>, exactly like it but nestable. So you are able to use any runes and write any code as you already can, just without seemingly arbitrary limitations of component syntax. Though this feature seems bigger in scope and as such more complicated to add, just throwing an idea out there.

With regards to syntax Marko 5 had both inline and block syntax:

$ {
  let count = 1;
  let double = count * 2;
}

$ let count = 1;
$ let double = count * 2;

So it is possible to have both. Maybe svelte compiler could be smarter with detecting those statements so that something like this would be allowed:

{
  let count = $state(1);
  let double = $derived(count*2);
}

{let count = $state(1)}
{let double = $derived(count*2)}

In my opinion though denoting this with something other than just { } would make more sense, to not conflate with template interpolation.

What about having multiple <script> tags in one component/page? That would be closer to plain HTML, would be easy to parse, would naturally allow multiline code without looking odd, and would not necessitate any new magical syntax in the markup.

{#snippet counter()}
  <div>
    <script lang="ts">
      let count = $state(0);
      let x = 42;
      console.log("foo", x);
    </script>
    <button onclick={() => count += x}>
      {count}
    </button>
  </div>
{/snippet}

The one annoying thing with this is having to write lang="ts" everwhere, though that could easily be solved by declaring a default <script> tag language in svelte.config.js, or perhaps any child <script> tags just follow the primary one at the beginning of the page.

@firatciftci That would be a breaking change sadly as Svelte already allows to nest script tags and they are interpreted as regular html script tags.

@kanashimia I don't see why nested script tags wouldn't be able to continue working as regular HTML script tags, with added support for runes and other Svelte-specific functionality. Seems like a non-breaking change to me, though I don't know the internals of Svelte code that well.

Because they are executed when the component is mounted, and svelte doesn’t compile those afaik Not when the component is initialised, which is when the top level script is executed (or at least the compiled version thereof)