Deleted Comment
Logic wise, it took me a while to get it. I thought that a bridge could be valid as long as every tile in it could be construed to form a word with the adjacent tiles. i.e. a word could be valid across bends and words could overlap on more than one tile.
I got the idea because the example has the words "T U N E" and "E A T" as part of the bridge, but it could also be interpeted as "T U N E" and "N E A T" with "N E" being part of 2 words.
Maybe you could adjust the example to avoid any ambiguity for first-timers?
Great work. Looking forward to tomorrow's puzzle :)
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.