React: Suspense issues

[bvaughn]

I'm currently updating the new React DevTools to use suspense for more interactions (https://github.com/bvaughn/react-devtools-experimental/pull/196). This has uncovered three pain points that we should try to address:

1. Using the "two setState pattern" can be awkward if the priority is "normal" or higher (as was the case in my "keydown" event handler) because scheduler.next uses "normal" priority for this case. (This also applies to e.g. non-React event handlers, since the default priority for these is "normal" as well.) Temporary workaround - manually run the first update with user-blocking priority.

2. Offscreen updates cause user-blocking and normal priority work to be batched together (for unknown reasons). This makes interactions feel unresponsive. Temporary workaround - none (other than to stop using offscreen priority).

3. Fallback UI shown too quickly. One of the main reasons to use suspense in the "inspected element" panel to begin with is to avoid a quick flash of the "Loading..." fallback when a new element is selected. However, it seems like this is still happening even with suspense. Temporary workaround - none, since I don't know the cause.

Edit I think the first two items I reported were caused by a second/duplicate scheduler package that had gotten installed in DevTools as a transient dependency.

[bvaughn]

As a side note, it seems unexpected that "keydown" and "click" handlers (using React's event system) get invoked at "normal" priority rather than "user-blocking".

Edit After stepping through a few call stacks, I realized that this is because the project has two copies of the scheduler module.

[bvaughn]

I think the first two items I reported were caused by a second/duplicate scheduler package that had gotten installed in DevTools as a transient dependency. 😦

I'm still seeing an unexpected flash of the "_Loading..._" fallback though:

[bvaughn]

It looks like the fallback is being committed _right before_ the resolved data.

[philipp-spiess]

After stepping through a few call stacks, I realized that this is because the project has two copies of the scheduler module

Ohh! I was running into the same issues yesterday when I updated an example to use [email protected] and [email protected] and was super confused about what’s going on. Thanks for posting about that here!

Since the Scheduler has its own version number, I suspect that others will run into similar issues eventually. Do you think this is worth a warning? I suspect that this won’t be a big issue later when the scheduler will hit v1 as breaking changes would be more alarming.

[bvaughn]

Yeah, some kind of warning message would have been helpful, @philipp-spiess

[bvaughn]

I figured out the cause of the temporary "_Loading..._" fallback commit too.

The new usage of suspense in the DevTools relies on data about the selected Fiber being fetched (asynchronously) across a "bridge" between the DevTools extension and the page context where React is running. The code that was sending the "inspect" message across the Bridge was inside of an effect handler (since it needed to attach an event listener). The way I had originally written the code, this effect _itself_ was blocking on the suspended render (since both it _and the code that suspended_ were reading from the same selected-fiber-id prop).

The fix for this was to change the side effect code to read from a different prop, one that was updated by a higher-priority state update, so that it got fired _before_ the suspending render.

This is kind of subtle and is something we'll need to add good documentation around before the public API gets broader adoption. For now though I'm going to close this issue since it seems like there are no outstanding bugs.

[NE-SmallTown]

I think maybe you need edit the No.1 content of the thread because you just mentioned suspense but the fact is concurrentmode && suspense