Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My concern with using `key` for this is that it’s somewhat of a booby trap for future consumers of the component. It requires some kind of documentation that you need to hope they’ll read. TypeScript won’t help you. It’s not common enough that they’ll think to go looking for it. It’ll break silently and they won’t know until there’s a problem. Is the best practice to wrap a keyed-to-reset-state component in an unkeyed component and then exporting that? Seems like an odd pattern.


Not necessarily, the component itself can work without a key. Adding a key is just one approach to resetting component state from a parent. If a component can’t work properly without a key it should be wrapped further to make it usable rather than documenting it for all consumers.


That last bit seems like a recommendation that should be in the docs. It’s sensible from a “don’t leave boobytraps” perspective but it won’t be intuitive to many people. It’s one more little rule to learn, another comment on a sizable chunk of PRs. While it may be idiomatic and sensible JSX, it seems like an outlier for React, and I wonder if there’s an opportunity to improve the developer experience of this very common use case.


I think I agree. I commented a while back I prefer components that don’t reset state based on props anyway.

Use state as little as possible and keep things pure and you probably won’t need this.

Example: date picker only keeps the open/close ui state of the picker. The date is a prop and date change is an event.

Instead of original date being a prop. Current date being local state.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: