Support top-level `{@const …}`

[regexident]

Describe the problem

Currently the only way to have a top-level {@const …} to avoid redundant computation …

<script lang="ts">
    // ...
</script>

<ul>
    <li>{expensiveComputation().foo}</li>
    <li>{expensiveComputation().bar}</li>
    <li>{expensiveComputation().baz}</li>
</ul>

… is to wrap everything in a silly {#if true} … {/if} block:

<script lang="ts">
    // ...
</script>

{#if true}
    {@const result = expensiveComputation()}
    <ul>
        <li>{result.foo}</li>
        <li>{result.bar}</li>
        <li>{result.baz}</li>
    </ul>
{/if}

Describe the proposed solution

Given that the above silly hack works I see no reason why there shouldn't be first-class support for it:

<script lang="ts">
    // ...
</script>

{@const result = expensiveComputation()}
<ul>
    <li>{result.foo}</li>
    <li>{result.bar}</li>
    <li>{result.baz}</li>
</ul>

Importance

would make my life easier

[MotionlessTrain]

What is wrong with

<script lang=“ts”>
  const result = $derived(expensiveComputation())
</script>

<ul>
    <li>{result.foo}</li>
    <li>{result.bar}</li>
    <li>{result.baz}</li>
</ul>

which would be completely equivalent?

[regexident]

What is wrong with […] which would be completely equivalent?

Nothing really, except the bigger picture, from a language design perspective.

---

1. Language consistency

   Not supporting {@const} at the outmost (implicit) block feels arbitrary, rather than dictated by technical limitations.

   Exceptions like this end up having to be taught, learned, and remembered by users and tend to make languages harder to learn.

   Adding universal support for {@const} (i.e. accepting them in all blocks, explicit and implicit) would make the Svelte language more consistent, simpler and overall easier to learn.

   As counter-intuitive as it is, by adding a sub-feature (filling a gap) you end up making the overall feature/language simpler.

   ^{(Anecdotally: the Swift and Rust programming languages have been on a steady course of learning and copying from each others features. But while Rust is being thoughtfully designed and grown on a foundation of a fairly small and consistent set of mostly orthogonal and composable features, the same cannot be said about Swift, where the corresponding features tend to be incomplete, and inconsistent one-offs with almost every language feature having arbitrary edge-cases like these, making Swift 6 vastly harder to learn than Rust 1.8x, these days.)}

2. Clean code

   With the common code structure of having components stored state clustered near the top of the corresponding <script> block, right below the imports, etc, the const result = … would have to be all the way at the other end of the file, violating the co-locality pattern, since subjectively it belongs to the DOM block. (see principle of locality, below)

   Or it would have to be at the very bottom of the script block, thus violating the project's stablished code structure pattern.

   Writing code isn't the hard part of programming. Maintaining code and keeping it clean is. And small things like these add up.

3. Principle of locality

   Stuff that belongs together (and nothing else) should be co-located. Similarly you shouldn't have to make changes all the way up in the <script> block, just to make a small change that's only ever relevant to the DOM block.

4. Principle of least surprise

   Removing the outer block of your DOM block shouldn't require you to suddenly replace your {@const … = …}s with const … = $derived(…), let along have to move the replacements into a completely different part of the file. Same goes for the inverse: adding an outer block shouldn't require you to replace const … = $derived(…) with {@const … = …}, just to keep things clean and consistent.

[7nik]

2. Clean code

I don't really see how it impacts this. And even more, mixing the template with (large chunks of) code will make the code less clean.
Btw, you are free to order script, style, and template in whatever order you find nice, as well as decide on the order of JS blocks.

3. Principle of locality

If the template and the code are too far apart, maybe you should move them to their own component?

[gterras]

@const was introduced to solve some awkward situations in the template, not as a strict replacement of top-level const declaration which would bring even more awkwardness. Stretching the logic you could just allow complete JS in the template, which I'm not sure would be simpler or more coherent.

The docs could probably be more specific about why @const exists though.

[rChaoz]

I think const only being allowed in blocks or components speaks for itself - it's available in the places where you have more information that you do in the script:

{#if isSomethingAllowed()}
  Only computed when used/needed
  {@const value = ..}
{/if}

<Component>
  {#snippet children(param)}
    Depends on data not available in template, same case for each
    {@const value = computation(param)}
  {/snippet}
</Component>

From what I can tell, it's used to avoid duplicated computations depending on data not available at the top-level.

[Conduitry]

We have plans for more flexible {let} etc directives, that are also less magical because they won't include an implicit $derived. The proposal hasn't made its way into this repo yet, but in the meantime we're not going to be spending additional time on syntactical sugar for {@const}, as we're going to be deprecating it.