[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.

[SebastianKra]

Okay I see where you're coming from.

> if that change also didn't enforce that way of thinking

My gut says that your mental model would lead to overall more spaghetti than the current one.

I also think that remounting all the DOM nodes is the correct default, since it clears any uncontrolled input and open popovers. Any shared settings between routes/forms etc. are custom behavior for user-convenience and should require additional code.

> needs to be applied by the consumer of the component, not the component itself

Depends on how you look at it. In my mental model, the client is actually requesting multiple form components, each with a different default value. Like 50 list cells where only one is visible. It's not a coincidence that lists and state-resets are implemented with the same api. But if you want to colocate this behavior, there's still the option to build a small wrapper:

function FormWrapper({ item }) {

    return <FormInner key={item.id} … />

}

[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.

[SebastianKra]

It's not. Try some inputs in Figma or basically any numeric input:

- Focus an Input that only accepts numerical values

- Enter some non-numeric text

- Focus back out

My pattern is fairly common when you pay attention to it.

I'm not arguing that you should always use it; that's why I didn't replicate OP’s example. It’s just a demonstration that most cases have a solution that describes the intention more accurately than a dependency array.

The remaining cases can be solved by the workaround from react.dev or a userland alternative.

[merb]

Well what you did will often not stay as is and at least evolve into the antipattern (update the input from outside) the only alternative would be to create a new key to do that. And trust me there is a lot of useeffect Code which is not a good idea