RFC: List rendering reform

[nolanlawson]

Rendered

[ravijayaramappa]

One usecase that is not very clear about existing for:each is nesting iteration blocks, where the inner for:each directive is an immediate child of the outer one. What should be the behavior of the lwc:key in that case?
IMO, this semantic makes it more clear than the older one. One thread related this confusion
1

[nolanlawson]

Yes, exactly. With lwc:key on the same element as lwc:each, you know exactly where the key should be applied.

[jmsjtu]

I think we might need to slightly distinguish the way lwc:key is applied vs key. With for:each when the short-hand is used, the key is applied to the element containing the for:each:

<li for:each={items} for:item="item" key={item.id}>
    {item.name}
</li>

In the example, the key is applied to the li and not the {item.name}, whereas if it were a template the key would be applied to the children inside the template.

The reason I mention this is because when there is a nested loop where the outer loop is a template the key is only applied once:

stackblitz example (playground link)

<template>
    <template for:each={contacts} for:item="contact">
        <div for:each={contact.addresses} for:item="address" key={contact.id}>
            <section>{address.zip}</section>
        </div>
</template>

Note the key only appears on the div, applying a key on the section would produce a warning.

If I understood correctly, with lwc:each the new format would be:

<template>
    <template lwc:each={contacts} lwc:item="contact" lwc:key={contact.id}>
        <div lwc:each={contact.addresses} lwc:item="address" lwc:key={address.id}>
            <section>{address.zip}</section>
        </div>
</template>

How would the lwc:key={contact.id} and lwc:key={address.id} be applied in this scenario?

As long as there's a key on the div I don't think it's a big issue but might be slightly unclear which one is applied.

[nolanlawson]

@jmsjtu I think the example you provide is a bug in for:each. It doesn't make any sense to me that one loop must have a key, but the other loop must not have a key.

In the case you mention, I think the problem arises from the ambiguity of what, exactly, the key applies to:

<template for:each={contacts} for:item="contact">
    <div key={contact.id} for:each={contact.addresses} for:item="address"></div>
</template>

In the above example, does the key correspond to the outer (non-shorthand) template loop? Or to the inner (shorthand) div loop? It's ambiguous.

Another benefit of this RFC, IMO, is that lwc:key is never ambiguous. It always applies to exactly the loop on the same element, regardless of shorthand or no-shorthand.

[ravijayaramappa]

Overall it LGTM

[jmsjtu]

We could also mark for:each and iterator:* as deprecated to discourage usage.

[nolanlawson]

I think it might be a bit early to do this. Similar to if:true and if:false, we need to make sure first that we have a well-lit migration path. But we can figure this out later.

[pmdartus]

I would like to discuss whether or not we keep this constraint with the new syntax. IMO, we should make it optional but strongly encouraged. The main reason we ask developers to set a key on iteration is to improve list diffing and re-ordering.

However, components don't always render a list of keyed items. It is currently awkward for developers to render a list of text in LWC.

export default class extends LightningElement {
  tags = ["performance", "bug fix", "trust"]
}

To wrap around this limitation. developers usually use the text itself as a key.

<template for:each={tags} for:item="tag">
  <div class="tag-wrapper" key={tag}>{tag}</div>
</template>

However, this approach is problematic as it only works if the list contains unique values. To solve this issue, I have seen some LWC components generating random ids for each entry which is also not ideal.

Now that LWC developers are used to key their iterations, I don't think that it would be problematic to relax this restriction. As a side note, I am not aware of any other UI framework enforcing this restriction.

Update: I see that it is already discussed in "Making lwc:key optional".

[nolanlawson]

This is also discussed in #84 (comment).

[pmdartus]

Any thoughts on using {} to wrap the lwc:item instead of ""? It's something that I have always found inconsistent in the current syntax.

In LWC template syntax, the usage of quotes on an HTML attribute denotes a static binding. But in the case of lwc:item, it is used to indicate a dynamic binding to a variable.

For context, I was the one who originally pushed to wrap the lwc:item value within quotes to discourage users from using JavaScript expressions. That said, my view changed on this over the years. I would like to get the sentiment from the rest of the team on this.

[nolanlawson]

I think using "" would make the syntax more consistent with scoped slots:

    <c-child>
        <template lwc:slot-data="item">
            <span>{item.name}</span>
        </template>
    </c-child>

In my mind, the quotes mean "declare a variable with a given name," not "evaluate a JS expression." Also, if we change lwc:item, we would arguably want to change lwc:index, lwc:first, lwc:last, lwc:even, and lwc:odd as well, since they also declare a variable. For those reasons, I'm in favor of keeping "".

[pmdartus]

Any thoughts about adding compiler warnings?

[nolanlawson]

I think similar to lwc:if/lwc:else, it may be a bit early to add compiler warnings. Compiler warnings to me should (normally) be reserved for truly broken things (like using a key outside of an iteration, or invalid HTML syntax that is allowed by old parse5 versions). In the future, though – why not?

[nolanlawson]

@pmdartus raised another benefit: we could use Fragments as the root of each list item. This should make the vdom diffing much more efficient because we would be diffing fewer vnodes in cases where the list repeater has multiple top-level elements.

Today we can't do this due to key. A developer could technically put a different key on every top-level element inside of a list, which would defeat the fragment optimization since the fragment must have one key. The new proposal solves this since lwc:key is hoisted.

[nolanlawson]

Note: Angular has count which is not in this proposal. Maybe it's worthwhile for iterables/iterators where you don't easily have array.length.

[nolanlawson]

@pmdartus: Use case for making it optional:

• You have a list of tags, it's just a list of strings, they'll never change
• You use the tag itself as the key since the key is required
• Now imagine suddenly tags are duplicated, now you need a unique id for each tag
• Now you have to add special IDs or Math.random() to work around it

[nolanlawson]

@ekashida: We could add another directive like lwc:no-key to communicate that a key is not required.

[nolanlawson]

Or lwc:dangerously-set-no-key-this-will-be-slow-and-i-like-it-that-way

[nolanlawson]

I looked into how other frameworks do this:

• Svelte/Vue/Angular: keys are optional (Angular calls it TrackByFunction rather than "key")
• React: keys are not required, but you will get a console warning without them
• Lit: keys are effectively optional: you can use Array.prototype.map for the key-less approach, or the repeat directive which requires a keyFunction
• Solid: More subtle. <For> does not require an explicit key function by design since Solid already has fine-grained reactivity. However it is keyed based on referential equality. Whereas there is the alternative <Index> component which is non-keyed and designed for cases where referential equality doesn't make sense (such as primitives).

[nolanlawson]

Missing from this proposal: Vue has a way of iterating over objects (key/value) as well as array-likes. Given that Object.entries() exists, though, I'm not sure how valuable this is.

[caridy]

I have a positive sentiment toward this reform.