I agree with that comment that the current heuristics might need tweaking. If duplicate the App in my original demo you get entanglement if you click one button in each App, but not if you click both buttons in the same app. Seems backwards from what you would want to me.
codepen.io/GabbeV/pen/B...

Here is an example that is closer to what I'm actually trying to build. I expected a revalidation started while the increment was still pending to entangle, making them commit together. codepen.io/GabbeV/pen/Y...

Not quite sure what you mean. If I press both buttons the result doesn't go from 1 1 to 2 2 it also shows the intermediate 1 2 or 2 1.

Still curious about this if the CVE stuff has calmed down. Experimenting some more with this today and it feels very unintuitive. For a while I thought it was a load vs action thing but then I found scenarios where seemingly unrelated loads entangled while those in the linked codepen don't.

Gave up on day 4. Can't seem to get away from ts(2589) "Type instantiation is excessively deep and possibly infinite."

This is as far as i got:
www.typescriptlang.org/play/#code/C...

Day 3: www.typescriptlang.org/play/#code/C...

Day 2: www.typescriptlang.org/play/#code/C...

Here is the solution to day 1 bsky.app/profile/gabb...

Just do the regular AOC in the typescript type system. My record is getting to day 5 before giving up.

I think the confusion comes partially from some things calling act invisibly under the hood making it seem rare that you need it. But also from trying to run tests with real async things happening that can't easily be wrapped like real timers.

Having to wrap it around each "step" is the right mental model to have. React batches things happening in the same callstack and defers other things until idle. act tells React that some action would happen in its own callstack and that you want the deferred work to complete before continuing.

It was supposed to be leet. However early programming languages limited keywords to 3 characters.