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

The really subtle footgun that I see is unexpected state preservation. This is where the component isn't designed to be "reused" for completely different props. This is because the state has something about the props and will end up unhappy if they change.

Some common warning signs are generic parameters for components and using a prop as the default value for a state hook. But neither of these are a reliable indicator of a problem.

These bugs also often lie hidden for a long time because They can be hard to trigger because you need the same structure of components with a generic property changed. But when they bite they seem like impossible errors.

I've wondered if React could add a useStateKey([deps]) hook that would allow forcing a state reset if the given values change. This would work similar to a key attribute but be controllable by the code inside the component.



This was more explicit when implementing class based components than functional components because the class based API had explicit overridable methods for those aspects of the component lifecycle.

That issue probably wouldn’t exist except that React has to make some concessions to performance, therefore component reuse, therefore component state working in sometimes unintuitive ways.


This follows on from using props as an initializer - something that should be avoided if possible. Date pickers get gnarly here: is the date prop the initial date or the current one? I think it should be the current one, with a prop to handle date change.


I've seen this problem often, and not just in React.

I agree




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: