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