[compiler] Add enableUseKeyedState flag and improve setState-in-render errors #35230
Conversation
| ); | ||
| let isArgPrimitive = false; | ||
|
|
||
| if (instr.value.args.length > 0) { |
There was a problem hiding this comment.
I think we should consider a setState with no arguments to be a primitive right? Because we would be changing the state to undefined?
There was a problem hiding this comment.
I know we discussed the idea of allowing unconditional setState-in-render calls if you pass a primitive, but then we discussed that we could recommend useKeyedState() (behind a flag) and that feels like it is the more robust option. We had a question mark on whether we should allow unconditional calls w primitives in our diagram.
As a slight variation, we could continue to flag all cases of setState in render with an error along the lines of:
Error: Cannot call setState during render
Calling setState during render may trigger an infinite loop.
* To reset one state when other state/props change, use `const [state, setState] = useKeyedState(initialState, key)` to reset `state` when `key` changes.
* To derive data from other state/props, compute the derived data during render without using state.
Where the first bullet would change conditional upon enableUseKeyedState (the abvoe example is assuming it's enabled, if false suggest the manual implementation of useKeyedState)
| if (instr.value.args.length > 0) { | ||
| const arg = instr.value.args[0]; | ||
| if (arg.kind === 'Identifier') { | ||
| isArgPrimitive = isPrimitiveSetArg(arg, fn); |
There was a problem hiding this comment.
I expected that this would be something like: if (!arg.reactive && HIR.isPrimitiveType(arg.identifier)) { /* allow */ } - ie reusing type inference to determine if a value is a primitive. And likely combining with a !arg.reactive check because if the value being set is reactive, then it could still infinite loop even if its a primitive.
But see the larger comment about the overall direction and whether we want to allow passing primitives
|
useState This is killing the simplicity of react |
|
Note that useKeyedState is a user space hook at Meta. We’re just experimenting with different lint rules and how to help people implement specific patterns. It sounds like you’d prefer we make React easier to use, that’s what we’re trying to do, please let us cook. |
poteto
changed the title
…r errors Adds a new `enableUseKeyedState` compiler flag that changes the error message for unconditional setState calls during render. When `enableUseKeyedState` is enabled, the error recommends using `useKeyedState(initialState, key)` to reset state when dependencies change. When disabled (the default), it links to the React docs for the manual pattern of storing previous values in state. Both error messages now include helpful bullet points explaining the two main alternatives: 1. Use useKeyedState (or manual pattern) to reset state when other state/props change 2. Compute derived data directly during render without using state
|
@josephsavona Updated! |
…r errors (#35230) Adds a new `enableUseKeyedState` compiler flag that changes the error message for unconditional setState calls during render. When `enableUseKeyedState` is enabled, the error recommends using `useKeyedState(initialState, key)` to reset state when dependencies change. When disabled (the default), it links to the React docs for the manual pattern of storing previous values in state. Both error messages now include helpful bullet points explaining the two main alternatives: 1. Use useKeyedState (or manual pattern) to reset state when other state/props change 2. Compute derived data directly during render without using state DiffTrain build for [f99241b](f99241b)
…r errors (#35230) Adds a new `enableUseKeyedState` compiler flag that changes the error message for unconditional setState calls during render. When `enableUseKeyedState` is enabled, the error recommends using `useKeyedState(initialState, key)` to reset state when dependencies change. When disabled (the default), it links to the React docs for the manual pattern of storing previous values in state. Both error messages now include helpful bullet points explaining the two main alternatives: 1. Use useKeyedState (or manual pattern) to reset state when other state/props change 2. Compute derived data directly during render without using state DiffTrain build for [f99241b](f99241b)
Adds a new
enableUseKeyedStatecompiler flag that changes the error message for unconditional setState calls during render.When
enableUseKeyedStateis enabled, the error recommends usinguseKeyedState(initialState, key)to reset state when dependencies change. When disabled (the default), it links to the React docs for the manual pattern of storing previous values in state.Both error messages now include helpful bullet points explaining the two main alternatives: