Without setting the key, there will be a strange delay in the update of x-for. #4240

Nivdc · 2024-05-27T07:25:15Z

Nivdc
May 27, 2024

I'm not sure if this is a bug, but I'll post it here to help others who come after me.

I wrote a reproducible webpage example, but the code is a bit long, so I put it at the end.
Visit this webpage ( JSFiddle ) and click the switch button.

The first click will output:

a1=a1, a2=a1,
a1=a1, a2=a1,
a1, a2,
a1

Everything is normal.
But when you click the button again, it will output:

a1=b1, a2=b1,
b1=b1, b2=b1,
b1, b2,
b1

The data of the first x-for does not seem to be updated correctly.

example:

<!DOCTYPE html>
<html>
    <head>
        <script defer src="https://cdn.jsdelivr.net/npm/alpinejs@3.14.0/dist/cdn.min.js"></script>
    </head>

    <body>
        <p x-data="room">
            <template x-for="user in userList">
                <span x-text="user.name+'='+host.name+', '"></span>
            </template>
            <br/>

            <template x-for="user in userList" :key="user.name">
                <span x-text="user.name+'='+host.name+', '"></span>
            </template>
            <br/>

            <template x-for="user in userList">
                <span x-text="user.name+', '"></span>
            </template>
            <br/>

            <span x-text="host?host.name:''"></span>
        </p>
        <button x-data @click="sswitch">switch</button>
    </body>

    <script>
        let room={
            host:undefined,
            userList:undefined,

            setup(r){
                this.host = r.host,
                this.userList = r.userList
            }
        }
        let ra = {
            host:{name:'a1'},
            userList:[{name:'a1'},
            {name:'a2'},]}
        let rb = {
            host:{name:'b1'},
            userList:[{name:'b1'},
            {name:'b2'},]
        }
        document.addEventListener("alpine:init", () => {
            room = Alpine.reactive(room)
        })

        let changed = true
        function sswitch(){
            room.setup(changed?ra:rb)
            changed = !changed
        }
    </script>
</html>

SimoTod · 2024-05-27T14:54:17Z

SimoTod
May 27, 2024
Collaborator

it must be a bug to do with Alpine not thinking the user has changed (no key means that you use the array index as a key. because you are not even modifying the array but reassigning it in toto, Alpine thing that the item in pos 0 at the second rendering is the same as the item in pos 0 at the first rendering).
The documentation doesn't explain that well but you should always use a unique and relevant key if your x-for is meant to change and be re-rended multiple times.

In general, why are using Alpine in a non canonical way (Manually calling room = Alpine.reactive(room) trying to access data and change it from the global scope, etc), hard to say if the bug is caused by this specific setup (Your html is also slightly invalid because your script tag is outside the body although the browser is probably going to fix that for you when rendering).
x-data going to make your context reactive anyway, if you need to share data functionality between components, you can use Alpine.store. You also probably want to look into Alpine.data and put your logic in the component without using function and variables from the global context (it's more maintainable and less prone to errors if your components are isolated).

1 reply

Nivdc May 27, 2024
Author

Thank you for your suggestion.

ekwoka · 2024-05-27T16:02:59Z

ekwoka
May 27, 2024

So it's kind of two things. Not having a key makes change tracking much harder.

The second is Alpine trying to prevent circular updates, so if something needs to be recalculated multiple times, it won't allow itself to run the effect more than once in a cycle.

changing host causes the first one to rerender while it still has the original user, since the keys and such didn't change. When layer the x-for tries to give it the new user, it has already updated so won't do so again.

But mostly, x-for should never be used without a :key

here is a more canonical demo

The update on the first line is always one behind, due to the effect schedular not allowing the effect to be requeued.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Without setting the key, there will be a strange delay in the update of x-for. #4240

{{title}}

Replies: 2 comments 1 reply

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Without setting the key, there will be a strange delay in the update of x-for. #4240

Nivdc May 27, 2024

Replies: 2 comments · 1 reply

SimoTod May 27, 2024 Collaborator

Nivdc May 27, 2024 Author

ekwoka May 27, 2024

Nivdc
May 27, 2024

Replies: 2 comments 1 reply

SimoTod
May 27, 2024
Collaborator

Nivdc May 27, 2024
Author

ekwoka
May 27, 2024