Sync updates shouldn't cancel pending async updates entirely

[aleclarson]

Currently, when the queue is flushed, any pending async updates are cancelled.
To ensure that to props are never lost, the controller merges them into its merged object, which is iterated in the diff method.

Merging has the consequence of immediately starting the pending async updates, which I believe is rarely what the user wants. For example, let's say useTransition is running enter animations on its items along with the trail prop (creating a staggered effect). When useTransition is then passed an update, the trail prop is effectively ignored and all enter animations begin at the same time.

I think we can do better.

One idea is to attach a timestamp to every flush. Then we never need to cancel anything on flush. Instead, when a pending async update is ready to diff, it checks the timestamp of each animation it wants to update. If the animation has a greater timestamp, skip updating it. By never cancelling on flush, we ensure that end values are never lost. By attaching a timestamp, we ensure that newer updates take precedence over async updates.

Feedback wanted. Thanks!

[drcmda]

By never cancelling on flush, we ensure that end values are never lost.

I think that's super important. If timestamps can guarantee that values aren't lost, so that we stay deterministic, then i would say let's go for it!

Another way could be that updates check if there are outstanding queue chunks, merge their values to the next one, or if none exists, start a new diff/update cycle.

Would you want to create a small test for this? We could bombard it with complex usecases and try timetags out.

[aleclarson]

Would you want to create a small test for this? We could bombard it with complex usecases and try timetags out.

I would appreciate if you did, and I'll get the timestamps implemented. :)