Order of Component-Updates when more than one store has a new value

[michAtEl]

Describe the bug

I think I found a case in which Svelte updates components in the wrong order.

Reproduction

https://svelte.dev/repl/207e33065bdb41dcb53bfe8ebcfb8ced?version=3.55.0
Click the Button "remove".

There is an Error on the console: "Cannot read properties of undefined (reading 'points')"

In handleClick() (App.svelte):
Because of selected.set(...) all instances of ConnectionPoint will update in the next microtask.
Because of connections.set(...), some of these instances of ConnectionPoint should not exist any more, but Svelte tries to update them, before it updates the instances of Connection. This leads to the Error.

The problem would be solved, if Svelte would update the components in this order:

• first: App
• then: all instances of Connection (this should remove all instances of ConnectionPoints, that should not exist any more)
• then: all instances of ConnectionPoints

Logs

No response

System Info

repl, Svelte 3.55.0

Severity

annoyance

[Prinzhorn]

I don't know if what you're suggesting is possible. You are mixing props and stores. So on one hand you are passing down props (connectionId) but you also manipulate the stores, which directly "reach" into the other components (ignoring any hierarchy). So you end up with two competing sources of truth and expect them to be in sync. What you are suggesting would be something like this:

1. A store changes
2. Svelte needs to identify all components that use this store (which is a higher level task then just invalidating the individual spots)
3. Svelte needs to figure out if they are in some sort of hierarchy
4. Svelte needs to update the components according to the hierarchy and also understand then components might unmount

2 might not be possible, I think 3 is definitely not possible (intuitively, I don't know how Svelte works in detail). With props all these things just "happen" naturally.

If you want to keep using this pattern then you need to make your components more robust to data being (briefly) out of sync, e.g. in ConnectionPoint.svelte

-{connectionId} {$connections[connectionId].points[pointId]}
+{connectionId} {$connections[connectionId]?.points[pointId]}

https://svelte.dev/repl/3c4f72ebbd7e4b06ae75bc9a5f65c9dc?version=3.55.0

[michAtEl]

The stores should be the only source of truth. The data in the stores is always consistent. The problem is (as far as i unterstand) that stores update synchronously while the dom updates asynchronously. The store selected is updated first, so these dom-updates happen first. All instances of ConnectionPoint depend on selected, so they are updated. At this moment, the store connections already has its new value. The instances of ConnectionPoint, that should be removed, can't find their data in the store connections.
There is an inconsistency between the existing components and the components that should exist.

I understand that it might be hard to fix this issue. If this is not possible, it would be nice to have an additional chapter in the documentation. This chapter could explain:

• how updates of the dom work (async)
• how updates of stores work (sync)
• when all of this happens in the event loop
• issues like this and solutions for these issues

At the moment, i use code like this:

selected.set(...)
await tick()
connections.set(...)

I think this works because (please correct me if I'm wrong): tick() resolves, after the changes because of selected.set(...) have been applied to the dom. During these updates, the store connections still has its old value. connections.set(...) runs in the next microtask. Because of this, no task, that could potentially modify stores, could run between selected.set(...) and connections.set(...).

[michAtEl]

Here's a much simpler example showing the same problem:
https://svelte.dev/repl/0b2d23c3004b4192a0491d6167a4c620?version=4.1.1

Because of selected.set('b'); both items will be updated.
Because of items.set({ b: { text: "item b" } });, App will be updated. This Code removes Item a from the store.
The update of Item a happens after item a item a has been removed from the store. Because of this, there is an error, when the Component Item a tries to read item a from the store.

This might be a solution: Svelte seems to have list of items that need a update. Before Svelte processes this list: Sort the list so that components closer to the root are processed first. In this case component a would be removed before it is updated.

[dummdidumm]

Fixed in Svelte 5