[feat] Implement RFC 33 - Constants in markup

[tanhauhau]

Implementing sveltejs/rfcs#33

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with npm test and lint the project with npm run lint

[tanhauhau]

@benmccann hmm.. but the CI / Lint didnt complain about them. i wonder should we have a separate PR that lints .svelte files in the test folder and run it through all the files at once?

[benmccann]

I'm not sure it'd be possible to lint the .svelte files in the tests because so many of them are purposefully malformed, etc. to test error handling. I don't think we have to be a stickler for .svelte file formatting in tests, but I just saw a number of files where spaces and tabs were mixed, which makes it harder to read and thought we could at least be consistent on that

[Conduitry]

The test failures here look to be genuine, and appear to be related to TypeScript complaining about types.

[iamcalvintam]

Hi guys, what would be the showstopper here? This looks wonderful and I personally couldn't wait to use it.

[Conduitry]

I've just pushed a change to update the wording of a couple of compiler error messages.

@tanhauhau Is there a reason for only allowing {@const} inside the specific node types that you currently are?

In particular, why is {#await foo} {@const x = y} {/await} prohibited? What about the {:else} of an {#each}? In some of Rich's comments on the original RFC, he also used {@const} inside {#if}, which is also disallowed by this implementation. Were you trying to avoid having {@const} in places that weren't already creating their own new scope?

[iamcalvintam]

Based on my use cases for const, most of the time it would work best in an #each loop. But I believe it would be as useful in an #await as well to transform the returned response. Would be interested to hear your opinions, @tanhauhau . Also thanks so much for working on this PR.

[iamcalvintam]

Looks like the work is completed here guys? When are we expecting this to be merged

[iamcalvintam]

Thanks so much for the great work @tanhauhau !

[Theo-Steiner]

Wow, terrific work @tanhauhau!
I wonder if this should be included in the tutorial for each blocks?
We could modify the cat example by giving the cats a weight property but the property is in pounds (because an evil american made the cat list) so now the user has to make a @const to help non-imperial unit folks understand the size of the cats as well.

Task:

<script>
	let cats = [
		{ id: 'J---aiyznGQ', name: 'Keyboard Cat', weight: 8},
		{ id: 'z_AbfPXTKms', name: 'Maru', weight: 11 },
		{ id: 'OUtn3pvWmpg', name: 'Henri The Existential Cat' , weight: 15}
	];
</script>

<h1>The Famous Cats of YouTube</h1>

<ul>
	<!-- open each block -->
                 <!-- declare constant -->
		<li><a target="_blank" href="https://www.youtube.com/watch?v={cat.id}">
			{cat.name} is a healthy {catWeight} kg!
		</a></li>
	<!-- close each block -->
</ul> 

Solution:

<script>
	let cats = [
		{ id: 'J---aiyznGQ', name: 'Keyboard Cat', weight: 8},
		{ id: 'z_AbfPXTKms', name: 'Maru', weight: 11 },
		{ id: 'OUtn3pvWmpg', name: 'Henri The Existential Cat' , weight: 15}
	];
</script>

<h1>The Famous Cats of YouTube</h1>

<ul>
	{#each cats as { id, name, weight }, i}
		<li><a target="_blank" href="https://www.youtube.com/watch?v={id}">
			{@const catWeight = weight /  2.205}
			{i + 1}: {name} is a healthy {catWeight} kg!
		</a></li>
	{/each}
</ul>

Maybe {@const } should get a whole tutorial section of its own though?

[SarcevicAntonio]

@Theo-Steiner imo every tag should be introduced one at a time as to not overwhelm beginners.

[aradalvand]

Personally, I don't like the keyword const for this, I think {@value ...} or {@local ...} were actually more fitting, which were the alternatives suggested in the original RFC too — even something like {$: ...} to match the reactive declaration syntax, since these are really local reactive variables — the reason for this is because a {@const ...} is not really the same thing as a JavaScript constant but the keyword makes it look like it is, while it's essentially a Svelte-specific construct, plus there's also no {@let ...} or {@var ...} counterpart, unlike what one might intuitively guess, so I think it can be confusing.

[janosh]

Poor Constantine Plotnikov is being pinged to no end from this PR. 😄

[Conduitry]

🤷 I tried putting the reference in the commit message in backticks, but it doesn't seem like that prevents the ping there. Oh well!

[lukaszpolowczyk]

Wait, why doesn't it work in if else? :O

[opensas]

@tanhauhau Is there a reason for only allowing {@const} inside the specific node types that you currently are?

I also wonder it there's any reason why the @const tag couldn't be supported as a direct child of an {#if...} tag. I think it would be pretty useful. May be I'm missing something.

(I'm not sure if this is the right place to post this question, given that the PR is already closed...)

[julien-c]

I also wonder it there's any reason why the @const tag couldn't be supported as a direct child of an {#if...} tag.

It is now though, no?