> 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.
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 · 5h ago
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 · 17h ago
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 · 17h ago
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.
It’s basically that useEffect gets overused because the state hook is such a bad api.
SebastianKra · 6h ago
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 · 2h ago
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
unconed · 16h ago
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.
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.
> 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.
> 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 }) {
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".
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.
- 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.
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.