business logic can have complex ui interactions, which can affect multiple components in parallel.
the catch with multithreading is that these updates are async (round-trip between the app worker, vdom worker and main). while these round trips are blazing fast (worker messages take 0.x - 3ms), there are still edge cases with collisions, which can corrupt the state.
i made the decision intentionally, that components shall not lock parents while updating, since this would be bad for the overall performance. think of a toolbar where you want to update multiple buttons in parallel. this must not happen in sequence.
however, what we can and should do: before starting an update cycle, a component should check the entire parent chain (via parentId(s)). if a parent update is happening, wait until it is done. meaning: the parent which is updating needs to get a flag (array with component ids). once an update is done, in case no further update is scheduled, the component needs to trigger all updates for the components inside the wait-list array and the game continues.
benefits:
- at this point, bulk updates often get resolved by developers using
setTimeout() calls. these delays are often too long (bad for the performance).
- we can add (optional) debugging logs to notify developers about colliding updates, so they can easily spot these occurrences and act accordingly.
while developers should be smart about how they structure bulk updates, this new feature should improve the overall developer experience.
business logic can have complex ui interactions, which can affect multiple components in parallel.
the catch with multithreading is that these updates are async (round-trip between the app worker, vdom worker and main). while these round trips are blazing fast (worker messages take 0.x - 3ms), there are still edge cases with collisions, which can corrupt the state.
i made the decision intentionally, that components shall not lock parents while updating, since this would be bad for the overall performance. think of a toolbar where you want to update multiple buttons in parallel. this must not happen in sequence.
however, what we can and should do: before starting an update cycle, a component should check the entire parent chain (via parentId(s)). if a parent update is happening, wait until it is done. meaning: the parent which is updating needs to get a flag (array with component ids). once an update is done, in case no further update is scheduled, the component needs to trigger all updates for the components inside the wait-list array and the game continues.
benefits:
setTimeout()calls. these delays are often too long (bad for the performance).while developers should be smart about how they structure bulk updates, this new feature should improve the overall developer experience.