You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: unstable_useMutableSource throws error when mutated before subscribe #19948
Click on the Mutate button. Final Value is rendered without any error. (Success Mode)
Toggle to Error Mode and click on the Mutate button again.
Error thrown (and the UI is rendered with the Final Value when run from vscode)
Note: In our actual codebase (private), we are seeing this error at different instances e.g. component getting updated due to setState call in useLayoutEffect etc.
The current behavior
Seeing errors in development build.
The expected behavior
These errors thrown by useMutableSource should not showup on the UI and not passed to the error boundary as the component is eventually re-rendered with the latest state without any error.
@SreeniIO Thanks for the repro case and discussion. I've landed a solution in #20665 and I'd suggest reconsidering the workaround you mentioned. My reasoning is this (copied from the PR description):
Mutating a mutable source (or any external variable) during render is not expected to be supported. However this error message misattributes the mutation as a React bug.
Should this use case be supported?
This seems very similar lazily initializing a ref so it might be tempting to think it's okay. Mutable sources are external though, so modifying them during render is a side effect which makes it unsafe and unsupported. So while we could "support" this case in a very limited way, we shouldn't.
Activity
SreeniIO commentedon Oct 7, 2020
I'm using this workaround for now
https://codesandbox.io/s/usemutablesource-forked-0suof?file=/src/App.js:1126-1269
bvaughn commentedon Jan 26, 2021
Proposed solution (really just a better warning and error message) in #20665
bvaughn commentedon Jan 29, 2021
@SreeniIO Thanks for the repro case and discussion. I've landed a solution in #20665 and I'd suggest reconsidering the workaround you mentioned. My reasoning is this (copied from the PR description):