{#key} block

[tanhauhau]

Closes #1469

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

[Conduitry]

If you're keying on an atomic immutable value, and you update that value to be the same as it already is, does that trigger the contents to be re-created? I would hope not. Is this already handled elsewhere in the code, in that the keying value will never even be marked as dirty? Do you think this PR would benefit from a test for this situation?

What initially caught my eye, though, when I was looking at this PR was the key-block-multiple test example. Is the idea here that any invalidation of any of the elements in the array will cause the array to be marked as dirty? If one of the elements in the array is an atomic immutable value, and that's been updated to the same value as it already has, does the rest of the code know not to mark the array as dirty?

[tanhauhau]

Good point. I wonder what do you think about passing expression such as

{#key obj.foo}
   <div>{obj.foo}</div>
{/key}

{#key foo + bar}
    <div />
{/key}

{#key foo(bar)}
    <div />
{/key}

which means we need to evaluate the expression when it's dirty and compare the value to determine should trigger the re-creation.

which mean that if writing

{#key [foo, bar]}
    <div />
{/key}

will always recreate if foo or bar is dirty, since the expression itself will always evaluate into a different reference

[Conduitry]

It looks like this partially attempts to add support for animation inside {#key} blocks, but something like

{#key foo}
	<div animate:bar/>
{/key}

still throws the validation error "An element that use the animate directive must be the immediate child of a keyed each block". Do animate directives make sense within {#key} blocks? Should some of the code this PR adds be removed, or should the validation here be relaxed?

[tanhauhau]

i wonder what are the use cases for animation in {#key} block. 🤔

if the key condition changed, elements are destroyed and recreated, transition will be triggered.
if the key condition unchanged, elements are kept intact, -> animate?

[Conduitry]

I'm not sure, I couldn't think of one off the top of my head, but this PR contains a validation check that returns the message "An element that use the animate directive must be the sole child of a key block" when it fails - so I'm guessing then that this is mostly a copy-paste from some other code?

If this wasn't an intended feature of your PR, I'd vote this animation-related stuff gets stripped out entirely for the time being.

[tanhauhau]

yes. that's copy paste code from {#each} block. let me remove it. 😅

[Conduitry]

Does this contain an analogous fix to the one in #5447?

Edit: Maybe that question doesn't really make sense...

[tanhauhau]

Yup. just to be sure, I added another test case that is analogous to #5447, where the variables in the key are not referenced in the template