Svelte 5: Local variables in the markup using @let

[kauderk]

Describe the problem

Right know the @const tag is too restrictive. It got better over time but still #7241

{@const topLevelConst = "im alive!"}
{topLevelConst}
---
{@const} must be the immediate child of {#if}, {:else if}, {:else}, {#each}, {:then}, {:catch}, <svelte:fragment> or <Component>

Describe the proposed solution

This is marko's tag api syntax example but the svelte equivalent would be {@let = ... }. The idea is to have local variables in the markup.
With the arrival of Svelte 5 Runes (fined grained reactivity) it makes sense to describe intent where it's needed, the current approach is to hoist variables at the script level and use them down in the markup.

// Say we have to reference/use a variable on a unique location
// alike {@const myConst = 'unmutable'}
// but it would be something like...
// {@let myValue = 'mutable'}
let/count=0
<button onClick() { count++ }>
  ${count}
  // it's mutable
</button>
// and cascades
${count}

// another example would be loops 
// and the abillity to have "local" variables

<for|index| from=0 to=10>
  <let/count=index/>
  <button onClick(){ 
    // see, you have complete access to this variable and its state
    count++ 
  }>
    ${count}
  </>
</for>

Alternatives considered

The alternative is to write crazy code :v

// deep nested markup
{#if true}
	{@const value = 'world'}
	Hello {value}
{/if}

Importance

would make my life easier

[wbhob]

This would be an anti pattern, as Svelte prioritizes separating state and logic from templates. So, putting additional state in the template would make tracking bugs more difficult.

To accomplish what you're trying to do the Svelte way, you just want an array of counts, and each item updates its entry in the array. @const is just a convenience to help you not rewrite the same property over and over, not a way to declare additional state or logic.

<script>
const { totalCount } = $props()
let counts = $state(new Array(totalCount).fill(0))
</script>

{#each items as item, index}
  {counts[index]}
  <button onclick={() => counts[index]++}> Increment </button>
{/each}

[kauderk]

Solid response. I guess I'm coming from the point of view of highly interactive systems and rapid iteration, where touching two or more places to add functionality has become a hurtle as I develop my apps. I won't put my self out there but I'm making a timeline/video/editor (many instances per client) that can be hosted on clients/websites in real time.

I knew I reached a threshold with svelte when the bundle sizes were unmanageable and code splitting was stopping development. With the arrival of Runes my problems could go away but I feel like the Svelte language itself changed its ways, I'm referring to the abandonment of the dollar sign reactivity and "let" variables. This feels reminiscent of the transition from class components to hooks in React and devs where forced to rewrite their apps to keep up to date.

Right know I'm on a journey of swapping Svelte with a new framework - Am I crazy? Probably. But I'm treading carefully while using https://mitosis.builder.io/?outputTab to compile my existing svelte components to more performant framework with great primitives SolidJS or the framework that is years ahead of everyone else MarkoJS, if you saw that meme "Marko did it first" is because it did, in fact runes is almost exactly to what Marko was doing years ago.
I will close this issue, I apologies for the negativity and the off-putting issue. 🙁

[wbhob]

It's a good suggestion, just probably antithetical to how Svelte wants to do things. You may want to look at state classes in Svelte 5 for those "bundles" of state, or reorganize your components so the state that would otherwise be in @let can be scoped. Video editing is a hard UI to build in general, even without realtime, so kudos