3 ms·
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 yo
by sickcodebruh 4y ago
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.
- aeroaero 4y agoNot 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.
- sickcodebruh 4y agoThat 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.
- quickthrower2 4y agoI 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.