Hacker News Reader

Comment by sophiebits | Hacker News Reader

The lint rule Dan mentions (eslint-plugin-react-hooks/exhaustive-deps) will catch errors like this.

It’s also worth noting that most class components people write don’t handle all prop updates correctly – Hooks tend to be slightly harder at first but tend to have fewer pitfalls in edge cases, especially if you stick to the rules (which there are lint rules to enforce).

View on HN

But there's something to be said about needing a lint rule for the API to be safely used.

To play devil's advocate, this has always been the case with React. Newbies always mutate props or use setState incorrectly or in the wrong lifecycle methods. We've relied on linting to solve this for a long time now.

The nice thing about functional programming is that you can reason about execution and write lint rules to fix pitfalls that you can't detect with imperative programming.

I think the article touches on that point. Specifically, the lint rule points out a problem that a class implementation would also likely have. Except that you can’t easily lint the class implementation in a similar way.

The lint rule is not to appease React. It’s to show you where a component doesn’t handle updates. This is already very common with classes but those issues tend to stay unnoticed.

Unfortunately we use tslint so we'd have to add eslint just for this.

> It’s also worth noting that most class components people write don’t handle all prop updates correctly

I'm very guilty of this however I'm usually being intentionally lazy and assuming that a certain prop won't ever update. With useEffect it usually happens by mistake.

> Unfortunately we use tslint so we'd have to add eslint just for this.

This won't be a problem forever (https://medium.com/palantir/tslint-in-2019-1a144c2317a9) :).

Reply on news.ycombinator.com