Bug: Suspense does not [always] reset state of suspended components

[Malgalad]

React version: 18.1, probably 18.2 as well but can't chose it in CodeSandbox

Exhibit A

Steps To Reproduce

1. Open https://codesandbox.io/s/nice-danilo-ej7mlr?file=/src/App.js, click on "Add Resource" to create resource

The current behavior

This is a variation on the Concurrent Mode documentation sample, but without the Suspense wrapping the consumer of resource. Clicking on the button sets state of the FirstChild component, resource variable is truthy and SecondChild is rendered, which reads resource and throws out a promise, and suspends (is this the right term?) both FirstChild and SecondChild as SecondChild is not wrapped in Suspense. After the promise is resolved, both FirstChild and SecondChils are rendered.

The expected behavior

According to the documentation, previous issues and common sense (setting state is not inside Transition), both FirstChild and SecondChild are unmounted when Suspense shows fallback, so state of the FirstChild should be reset. Instead, it somehow preserves the resource inside state and renders SecondChild.

Exhibit B

Steps To Reproduce

1. Open https://codesandbox.io/s/funny-pateu-z4cr8t?file=/src/App.js, click on "Refresh"

The current behavior

This is a modification of the previous sandbox, but resource is first created outside of FirstChild and can be refreshed, without Transition and even inside setTimeout so that React can't be smart and track it as event handler. Additional state randomValue is present that is preserved after unmounting and mounting again.

The expected behavior

As previously, I expect that state is reset, and randomValue is a new number on every refresh. Same result if using useMemo or useRef.

Exhibit C

Steps To Reproduce

1. Open https://codesandbox.io/s/busy-mestorf-folp47?file=/src/App.js

The current behavior

Code is stuck in an infinite loop. A new resource is created not outside of component and not inside event handler, but during render. With everything else equal, and contrary to the previous two examples, it (apparently) does not save the state that has resource but resets it.

The expected behavior

Biiig question mark here. My expectations is that components inside Suspense are fully unmounted and lose all state, hence we need to either create resources outside of render tree, or place state with resources above Suspense, aka wrap children in additional Suspense. But that does not seem to be the case in the first two examples. Which means I have no idea how it should behave and if it is undocumented feature or a bug. Also, useEffects are also not running after unmounting-and-mounting, but useLayoutEffects do, which seems in line with React 18 RFC.

[jerelmiller]

I too experienced this recently while implementing suspense support for Apollo Client. I found this behavior quite surprising as my mental model led me to believe suspending a component is akin to "unmounting" it, hence why I expected the state to be reset.

Perhaps there is good reason for this behavior, and I'm willing to accept that, but I struggled to find anything in any RFC or discussion in regards to this behavior. At the very least, it would be useful to have this written down to avoid confusion.

[andrei-datcu]

I've also got bitten by this issue as well. I've been living under the same impression as the other folks here: I was expecting the state of the unmounted children to be reset. There still doesn't seem to be any mention of this behavior in the documentation. Can we rely on the current behavior to be preserved going forward?

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!