#each feels unnecessarily complex and far from JS

[mindplay-dk]

I decided to learn Svelte 5 and I'm just going over the tutorial.

The {#each} construct is extremely perplexing to me and feels unnecessarily distant from anything resembling native JS.

Problem

Let me explain with an example:

<script>
	let obj = {
		one: 'hey',
		two: 'yo',
		three: 'yo'
	}

	let array = [100,200,300];
</script>

<ul>
	{#each Object.entries(obj) as [name, value] (name)}
		<li><strong>{name}</strong>: {value}</li>
	{/each}
</ul>
<ul>
	{#each array as value, index (index)}
		<li><strong>{index}</strong>: {value}</li>
	{/each}
</ul>

First of all, looping over object properties is common enough in JS, and this was hard to figure out, first of all, since #each works like a for..of and can't be used like a for..in, so you need to manually call Object.entries to turn the object into an array - which, besides being unintuitive, makes me wonder about the performance.

Then there's the (key) syntax. I legit cannot figure out what these expressions are relative to? It seems the key expression can reference a symbol you've already defined on the right-hand side of as - but it also accepts expressions like name[0], which I assumed would mean e.g. first letter of name? But the error message suggests something completely different:

each_key_duplicate Keyed each block has duplicate key three,yo at indexes 1 and 2 in App.svelte

It appears the key is being set to the whole tuple value and name[0] does not actually do anything? name[0][0] produces the exact same error, so it would appear this syntax is just being ignored entirely.

Even for the plain array loop, I am not confident that (index) does what I think it does.

I've gone over the docs and the tutorial again and again, and I can't make any sense of it.

Suggestion

Why don't we align this better with JS terminology and behavior?

So for objects, make this directive more closely resemble the for..in syntax:

<ul>
	{#for name, value in obj (name)}
		<li><strong>{name}</strong>: {value}</li>
	{/for}
</ul>

Of course, a regular for..in only accept name and not name, value, but I think that's a fairly intuitive enhancement - something that's frankly just missing in JS proper.

As for the (name) suffix, obviously this isn't plain JS either - and, honestly, I would give real consideration to just omitting this feature. Just make me use a {#key} block instead - that would be fine. If you do have this feature, I would expect (name) has to reference something you've already defined or destructured in the name/value expressions. (I still don't understand how the key expression is evaluated in the current {#each} directive.)

If this internally needs to call Object.entries, or add the boilerplate Object.hasOwnProperty sanitization, that's an implementation detail that's very unlikely to get in anybody's way.

Similarly, for arrays, make this directive more closely resemble the for..of syntax:

<ul>
	{#for index, value of array (index)}
		<li><strong>{index}</strong>: {value}</li>
	{/for}
</ul>

Again, the only deviation is the addition of the value, index pair, something JS should have had - and the (index) key reference, which I'd be perfectly happy to get rid of.

Small thing, but the {:else} directive is going to make a lot more sense in conjunction with {#if} as well:

{#for todo of todos}
	<p>{todo.text}</p>
{:else}
	<p>No tasks today!</p>
{/for}

The presence of little keywords like in, of and as in the same file is just confusing - these words have very weak semantics and it's just too easy to get these mixed up and get confused. We can't get rid of in and of, and JS developers already understand these, but I feel things get muddy when we throw as into the mix as well.

Working with a template language, you're going to be going back and forth between JS code and templates a lot - for something as fundamental and essential as loops, wouldn't it make sense to align the terminology and behavior more closely with the language you're using the other half of the time, when you're not writing templates?

Contrast this with {#if}, which is immediately intuitive - it looks and works just like a regular if..else statement, only with the minor addition of the template block syntax. (something I've wished JSX would have had, since forever.)

By comparison, the {#each} directive deviates from JS in so many ways besides just the block syntax.

It just feels like unnecessary learning curve for something everyone already knows from JS.

Thoughts? 🤔

[brunnerh]

Changes to #each would have little actual effect and cause a lot of unnecessary churn (which would be forced since this would be a breaking change).

As for how a keyed #each works, that has been answered e.g. here.

[mindplay-dk]

Not going to happen. Svelte only provides one way of doing things if at all possible.

Plenty of features have two or more flavors or syntax variants - many (most) of which are clearly just there for convenience.

So, not really seeing your point there - though in general I agree with the idea of fewer options == higher consistency, in this case it's not about merely providing convenience or prettier/shorter syntax, it's about improving familiarity and consistency with the language. I would expect a new and improved loop syntax would be recommended, effectively replacing the old syntax, while preserving the current syntax mainly for backwards compatibility.

Please read the {@debug} documentation 😑

I did read the documentation - it doesn't mention loops. I don't know how I would reference the nameless key inside the loop?

I get the feeling you're annoyed with me for some reason. I hope you don't think I'm here arguing for the sake of argument. 😐

I don't see why anything I'm suggesting is unrealistic? Introducing a more familiar, alternative syntax is not a drastic change, is it?

As stated, there will be no competing syntax that achieves the same thing. The only alternative would be replacement, which is unrealistic for the reasons I outlined at the very start.

No offence, but is that your decision?

Sorry, but I don't know who you are. Do you have some sort of role on the Svelte team? Your profile doesn't say.

(please don't take that the wrong way, I'm just trying to understand who I'm talking to here.)

(if you do have some sort of assigned role, I do appreciate your taking the time to discuss!)

[brunnerh]

I did read the documentation - it doesn't mention loops. I don't know how I would reference the nameless key inside the loop?

I get the feeling you're annoyed with me for some reason. I hope you don't think I'm here arguing for the sake of argument. 😐

If you read the docs, you should have noticed that values need to be supplied.
And as I stated:

The key is constructed from the item (and potentially any symbols that are in scope at this point).
These values can be inspected in the #each via {@debug}.

So you just provide any values that make up your key. If you want to get the exact expression in case you do something more complex than a property reference, you could use a @const to rebuild the key.

<script>
	let items = [
		{ first: 'a', last: 'a' },
		{ first: 'a', last: 'b' },
		{ first: 'b', last: 'a' },
		{ first: 'b', last: 'b' },
	]
</script>

{#each items as { first, last } (first + last)}
	{@const key = first + last}
	{@debug  key}
	<div>{first} {last}</div>
{/each}

Playground

I am indeed annoyed, because it does not look like you are making much of an effort to read up on things at all - first with #key now with @debug.

---

Who is you?

I am a Svelte "ambassador" - I am not a maintainer but get to be somewhat involved in the design process. I also try to help out on issues, providing workarounds, answering questions, finding duplicates and related issues.

Given that, I have seen many suggestions like this one which have been shot down because they would introduce alternative new syntax without enough added value.

Also, as I suspected, this has been brought up before and rejected:

• Consider adopting for..of instead of each..as for iteration #4350

I’m afraid this isn’t something we are interested in. We don’t want to add two different sets of syntax for exactly the same thing. This has been discussed quite a bit in the past.

[mindplay-dk]

I am indeed annoyed, because it does not look like you are making much of an effort to read up on things at all - first with #key now with @debug.

I'm sorry, but I do read both the reference docs and tutorial on every topic - I try to solve any problems before posting.

The confusion here is I wanted to see what is actually assigned to the invisible key - you're suggesting to just define some other variables with the same expression/value, but that doesn't tell me what is actually assigned to the key.

When you suggested {@debug} I took that as you suggesting the key could be inspected with that.

But I get it now - there is no way to see what the key is.

This is part of the insecurity and confusion I'm trying to point out - having an invisible variable is extremely unusual in a JS context. And it somehow gets assigned as the key. I get it now, it just happens, and it's how the syntax works. But at the same time, the {#key} directive exists - and so, perhaps you can understand, coming from React (or really most JS frameworks) the key is usually something we need to assign ourselves, and the {#key} directive could seem to suggest that's an option.

Most developers are going to be arriving with React experience, and/or experience from other frameworks that lean React-like.

Would it be too surprising if most newcomers run into the same questions and confusion at some point, I don't think so.

If they're not coming from React, they're almost definitely coming with some sort of JS experience and will run into surprises with loops.

But fine, you don't think this is worth solving.

I have nothing more to add, so I will leave you alone now.

Again, thank you for your time. 🙂

[brunnerh]

Regarding React and people coming from JS backgrounds:
Svelte is fundamentally HTML-centric, that is something people will have to get used to.

See the tenets:

HTML, The Mother Language

HTML is a really good language for describing UI. Svelte augments HTML in a way that makes it a really good language for describing interactive UI.

Most frameworks are JS-centric, because JS is the most powerful language. But then they find themselves jumping through hoops to make it feel like you're writing HTML. We think both options are valid, but the HTML-first approach ends up feeling more natural.

In a way #each being #each rather than #for has its advantages:
It does not pretend to be something it's not. A DOM-synchronizing list is just not the same as a plain JS for loop. There will unfortunately always be room for confusion because of keying, the rename would not change that.

But fine, you don't think this is worth solving.

I am all for improvement, but changing the syntax in this way does not pass the cost/benefit calculation.
If you have suggestions for improving the docs, feel free to open an issue - the docs can always be improved.

Again, thank you for your time. 🙂

You are welcome.

[mindplay-dk]

I want to leave it alone, but 😅

It does not pretend to be something it's not. A DOM-synchronizing list is just not the same as a plain JS for loop.

but it's close enough. What it does with the elements it iterates over is different - but the iteration itself is (at least conceptually) the same as a for..of loop - there's no reason to pretend it isn't.

and I don't think that was the motivation for making it look so different? most likely, this was inspired by Handlebars. (I have no idea where Handlebars got the idea - there doesn't seem to be a lot of programming languages that use this syntax.)

There will unfortunately always be room for confusion because of keying, the rename would not change that.

well, there are meaningful differences that can't and shouldn't be changed - but then there are meaningless differences like arbitrary keywords and the backwards token order, that could be.

I get it, the cost/benefit calculation, that's fair - but no, I can't make myself reframe arbitrary differences as "a good thing". 😌