Updating component that makes resource request triggers update warning

[pshrmn]

Do you want to request a feature or report a bug?

Bug, but more of a minor annoyance.

What is the current behavior?

tl;dr Updating a component that makes a resource request which trigger state updates causes a warning to be displayed.

(This description is based off of a modified version of the unstable_async/fixtures example.)

Given a component that makes a resource call, which triggers React updates.

const someResource = createResource(fetchUserData);

function UserDetails(props) {
  // another component is "plugged in" to this resource, so
  // calling read() will trigger setState() calls in that component
  const data = someResource.read(props.id);
  return (
    <div>{data}</div>
  )
}

When the resource requesting component is mounting, it is an indeterminate component. During updates, it is known to be a functional component. In both instances, the component is called to get a return value. The difference being that when it is known to be a functional component, the renderer's phase is set to render before calling the function.

// mountIndeterminateComponent()
const value = UserDetails(...);

// updateFunctionalComponent()
setCurrentPhase('render');
const value = UserDetails(...);
setCurrentPhase(null);

Because the phase is set to render for the functional component, we get a warning that React Cannot update during an existing state transition... (from warnAboutInvalidUpdates()).

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

https://codesandbox.io/s/0484pzv330

This is the unstable_async/suspense demo, but has been modified to add a button to navigate the user details for acdlite from any other user page.

1. Click on any user (besides Andrew Clark, the warning is only triggered when his data is not cached).
2. Click on the Go to Andrew Clark button.

In the console, there will be a warning about updating during an existing state transition.

What is the expected behavior?

No warning

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

Master build

[gaearon]

Can you turn this into a failing test for ReactSuspense-test?

[acdlite]

calling read() will trigger setState() calls in that component

That seems wrong. read should not result in a setState. That’s exactly what this warning is for.

(Can’t open your example now because I’m on plane Wi-Fi)

[gaearon]

Can you create a smaller repro? This one is pretty involved.

[pshrmn]

Pared down demo: https://codesandbox.io/s/o9x1n07yx5

The "show file loading" option controls whether the <Debugger>'s showProgress() function (which calls setState() and triggers the warning) is called. The warning only happens once and with requests that have cache misses, so you might need to do a hard refresh when toggling this state.

[gaearon]

This is still a lot of stuff (with Debugger etc). Can you boil it down to its essence?

If the problem only occurs when read() synchronously leads to setState() I think it's fine to be unsupported. My "debugger" is just a hack for a demo, and not meant to be used in the same way.

However if the problem is legit we should fix it. For example if it happens because we don't reset the "current method" after a throw.

[pshrmn]

I cleaned it up a little bit, but I think I would lose functionality if I cut anything else out.

I guess that what it boils down to is that the resource fetcher is performing side effects when it calls the function that triggers the <Debugger>'s setState(). If this behavior is discouraged, then I'm not really worried about it.

Also, the side effect update only works when there are two React roots. If I render both the <Shell> and <Debugger> under the same root, then the state update during the <UserDetail>'s render phase is lost (in which case, the warning is useful).

[gaearon]

I don't understand where the fetcher synchronously calls setState. I only see an async call (so technically it doesn't happen "during" render). Which means it might be a React bug.

[gaearon]

Never mind, I was wrong. I missed that Promise constructor callback fires synchronously.

In that case the behavior makes sense to me. It's indeed a setState in render which isn't encouraged. My example does it because it's hacky.