React's useState should require a dependency array

[unconed]

I've written a similar `useDerivedState` hook before, which is basically formalizing the lastValue !== value / setLastValue pattern that the docs teach you.

But there is a major blind spot. The reason you want the dependencies is to reset the state when the outside demands it. But only way you can reset such a state is if the dependency _changes_. So it's not possible to reset the state back to the _same_ value as before.

To do that, you either need to manually manage the component lifecycle with a `key={..}` on the outside, or, you need to add e.g. a `version={N}` counter as an extra prop, to handle the edge case. Except, at that point, it makes more sense to rely on `version` entirely.

The 'proper' solution I've found is to actually write code to do what the policy and etiquette demands. E.g. for a number input, you can't aggressively reformat the contents because that's unusable, but you can check if the current text parses to the same value as before (if it is a valid number). There is no way to hide this sort of nuance with a generic state hook, it's too context-specific.

What is most useful is to treat the bridge between controlled and uncontrolled state as its own wrapper component, e.g. called <BufferedInput>, which has a render prop to actually render the <input> itself. It accepts a `value / onChange` on the outside, but passes on a different `text / onChange` to the inside. Give it a `parse`, `format` and `validate` prop that take functions, and you can clean up a lot of messy input scenarios.

[SebastianKra]

> Call it contrived, but maybe we want to add drawings to our tasks. With different brush colours

That's when you lift state up - either to the parent component, or put the value in local storage. Both as a user and as a developer, my mental model is that each item in the list has it's own form, rather than sharing one.

I haven't seen enough instances of this problem that I think it would warrant a change to the core api's. Maybe you could demonstrate more real-world examples?

A pattern that I sometimes like, is an internal state that is set only if the input is dirty. This has the advantage of preventing external updates from interrupting the user while they're in the middle of typing.

    function NumberInput({ value, setValue }) {
        const [tempValue, setTempValue] = useState(null)
        
        function submit() {
           const parsedValue = parseInt(tempValue)
           setTempName(null)
           if (parsedValue !== NaN) 
               setItemName(tempName)
        }
        
        return <Input value={tempValue ?? value} onChange={setTempValue} onBlur={submit} />
    }

[jaaamesey]

I'd agree that generally, using `key` to reset state at the component tree level is fine, and that good component structure or persisting state through other means makes it a lot harder for this issue to come up.

> my mental model is that each item in the list has it's own form, rather than sharing one

100% - it makes things a lot easier to reason about if you're guaranteed to have a fresh instance of a component for each item being switched to. In fact, if I saw that stale state issue come up again in production, and it wasn't the kind of thing avoiding state entirely could fix, my suggestion would just be `key` instead of reaching for a third party hook.

I wouldn't be suggesting a change to React itself if that change also didn't enforce that way of thinking, albeit at the hook level instead of component tree level. `key` always felt like a weird escape hatch to me in that:

- it's not a solution lint rules would nudge someone towards

- `key` needs to be applied by the consumer of the component, not the component itself

- we lose all state in the tree and re-create all DOM nodes

I'll admit that it's hard finding good examples of where that last thing is an issue. The only other one off the top of my head might be preserving component/DOM state between route changes, e.g. keeping the same scroll position in a list of filters between similar screens for searching products. These issues only really come up when you have a deep component tree and lifting components up gets much trickier than having state reset naturally and atomically.

[PaulHoule]

I think in the cases where you'd want useState to have declared dependencies you don't want to use useState.

The people who started the system I work on now had the bad habit of copying prop variables into state variables for no good reason and over a period of time I've removed those state variables, pushed state up, and followed the mantra that "props are preferable to state".

[merb]

What you now basically did is an antipattern. Because your example gets quite messy if the outer state gets updated and the component should render the new value. I mean even react itself acknowledges the problem.

https://react.dev/learn/you-might-not-need-an-effect#updatin...

It’s basically that useEffect gets overused because the state hook is such a bad api.