Why is this necessary? Can we rewrite the test somehow? I can pair with you on this if needed

If you rebase on master, you can wrap the concurrent tests with an __EXPERIMENTAL__ check instead.

I... don't understand the purpose of this (why 'A' is in the yields). deferredText will finish the current commit with the old value, and then update itself in a separate commit, but why? Doesn't <Suspense> already do that "for free"?

The yields are not important. The output is important. If it was using Suspense, the output would be [span('B'), span('Loading')] which isn't desirable here.

I'd expect Suspense to hold off on committing the subtree at all (so it'd stay showing span('A')) until the expirationTime is reached.

...though I guess act() forces an expirationTime flush.

In that case we couldn't commit the outer A so it would be [span('A'), span('A')]. We have another way to do that which is what useTransition is for.

We never commit anything in an inconsistent state by default. So either we commit A in both slots or B in both slots. Early explorations included ways of leaving some trees inconsistent but the downstream effects on that in a reactive system was too difficult to reason about. E.g. imaging you also switched to Dark Mode in a Context at the same time.

useDeferredValue is a limited form of explicitly opting in to inconsistency for a particular value while keeping other values consistent.

Does the callback run as a potentially separate commit, or does being inside Scheduler.next prevent non-explicit "unbatching"?

The intention here is to:

1. Set pending false at high priority
2. Batch setting pending to false and doing the actual state change at lower priority

As a result, you'll see pending immediately turn true, but then it turn false together with the actual state change you wanted to do.

This is the only built-in hook producing a pair which returns a function as the first, instead of the second element. This will take some education.

That does seem odd. Should it be flipped?

The first argument is useful without the second but not the inverse.

Shouldn’t we nudge you to use the busy return value tho?

Why do we not pass the TimeoutConfig to Scheduler.unstable_next in the mount case, when we do in the update case?

Nice catch. unstable_next doesn't accept a second argument. It must have been a copypasta from withSuspenseConfig.

Yeah, it was accidental copy/paste. Deleted it! :)

This config doesn't seem right. Probably a copy paste error.