Updating a keyed {#each} triggers lifecycles in reverse order

[farism]

Describe the bug
Updating a key list causes onDestroy/onMount lifecycles in reverse order

Logs

mount {item: "item 1"}
mount {item: "item 2"}
mount {item: "item 3"}
mount {item: "item 4"}
mount {item: "item 5"}
mount {item: "item 1"}
mount {item: "item 2"}
mount {item: "item 3"}
mount {item: "item 4"}
mount {item: "item 5"}
swapping unkeyed list1
destroy {item: "item 4"}
destroy {item: "item 5"}
swapping keyed list2
destroy {item: "item 5"}
destroy {item: "item 4"}
destroy {item: "item 3"}
destroy {item: "item 2"}
destroy {item: "item 1"}
mount {item: "item 8"}
mount {item: "item 7"}
mount {item: "item 6"}

To Reproduce
https://svelte.dev/repl/e8f06d587e3343ba8b4d1c61d94e380f?version=3.15.0

Expected Behavior
Updating a keyed {#each} block calls lifecycles in natural DOM order

Additional context
I'm kind of relying on the initialization order to be "correct" because I have a set of components that (Parent/Child) and the child component registers itself with the parent. It would be nice if this registration happened in order so that I could use it for things like navigation, or other features.

[Crisfole]

Would you be equally content with documentation that mount/unmount is not guaranteed to occur in predictable or consistent order?

A few thoughts relevant to your situation:

1. Relying on the order of DOM operations is probably going to result in breakage when you upgrade svelte. Because svelte tries to optimize things it's fair to assume the order it ultimately does things could be different as long as the resultant DOM structure is consistent.
2. I think in general Svelte encourages self-contained components. As a rule parents give instructions and data to children, children can't really talk back...I wish real children worked this way.
3. If you can find a way to model the state in javascript and then render it with svelte you may wind up fighting the system less.

[farism]

I think there should at least be a note in the documentation, yes.

To give a bit more information on my use case, I'm using context to register children during initialization with their parent, and then there is some key handlers to navigate between items. It's basically a menu with items having an "active" state and im using store/context to track the active item. So I'm using a feature specifically for child/parent communication haha. Also I can post a repl if this is still confusing.

I can probably get around this issue by requiring the user to provide their own index when rendering out the children items, but seeing how my project is a UI library I was hoping to hide those implementation details. Not to mention only certain items are registered based on some criteria so that's additional logic the user has to be aware of.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.