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

>It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them ... missing dependency accidents requiring linters to prevent

Infinite loops and missing dependencies are/were issues with `componentDidUpdate`/`componentWillUpdate` and `componentDidMount` as well, though. On the plus side, you now have a linter which can both point out these errors and automatically fix them for you. I agree that the whole thing is a bit leaky and dumb though, but there's no way to fix that without introducing some sort of compilation/optimization step and afaik the React guys aren't really considering that at the moment.

>Weird, unexpected reference issues

Not sure I've run into this before. Do you have any examples?

>strange programming patterns, a team member having to write a terrifying novel

The first bit seems like personal preference or something, not sure what you're referring to as strange. The `useEffect` novel exists because a ton of people had built up their (incorrect) mental model of how React works with lifecycle methods and were making mistakes or running into unexpected behaviour because they assumed `useEffect` was the exact same thing as `componentDidMount`.



Reference issues:

1) Needing an advanced understanding of closures. Not always, but sometimes. That "sometimes" is often unintuitive, requiring weird solutions like useRef. Good luck beginners.

2) Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire. Seems fine, and is mostly fine in most cases, but hey, oftentimes not fine, and why that's so is not always clear. So then there's memoization, and useCallback and all of these safety checks -- each with their own dependencies array that need to be checked. It's really too much tbh. There are lots of solutions out there that use proxies to check this stuff; React should have baked that into the core and completely removed that responsibility from the user unless they wanted to opt-in micromanage performance of their code.


> Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire

This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?




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

Search: