Hacker News Reader

Comment by azangru | Hacker News Reader

Calling useEffect an escape hatch is as much of a recent fad as shitting on react. How can it be an escape hatch, when it is the only api provided by react to perform side effects during the rendering cycle, which do not themselves pertain to rendering? Calling it an escape hatch is the same as calling componentDidMount or componentDidUpdate methods of the class-based api escape hatches.

View on HN

I mean the react docs literally call it an escape hatch[0]. First sentence.

[0]https://beta.reactjs.org/learn/you-might-not-need-an-effect

That’s bad wording though. A fundamental building block shouldn’t be called an escape hatch.

Ah yes. It’s the docs that are wrong.

I understand why it’s worded that way in this specific article. But it’s still unfortunate to call it an escape hatch.

This term is typically used for ways of breaking the rules of a framework. With useEffect you’re still very much in React world and need to follow the rules to achieve much of anything with it.

The norm would be not to use an escape hatch. But I doubt there are many React applications that aren’t using useEffect.

In useEffect your code runs at a specific point, where it’s safe to bridge react to the outside world. It’s not about breaking the rules, as much as you have the ability to cause and react to side effects (eg a fetch promise) and inform react about the result (with a setState).

That’s much better explanation and more precise wording than the linked article did. I like the notion of “safe bridge”.

Reply on news.ycombinator.com