Hacker News Reader

Comment by andix | Hacker News Reader

One of the best things ever invented in component based frontend frameworks. It makes purely functional frameworks like modern react much easier to deal with.

Off course it's a violation of some theoretical principals. So what?

What I don't get: people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place. In my experience most ambiguous use effects can be easily removed. They are rarely needed for anything but library code or interaction with browser APIs.

View on HN

> people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place

I think this is the crux of the issue. One's view of hooks depends a lot on the sorts of codebases they've worked in. Maybe the sun has always shone on you, and you've only ever worked in projects where hooks have been used sparingly and with great consideration.

You're very fortunate if so. I've seen some truly horrific hooks-enabled messes that have had to be outright abandoned because they became too complicated for anyone to understand or debug.

Yeah that's a great point. Nothing makes me start really looking closely at a merge request than when a useEffect shows up.

My junior developers started to come to me with the question: how can I do this without useEffect? Because they already know that their PR will be rejected. Usually we can figure it out within a few minutes, and make everything less complicated.

People are just way too much thinking imperatively, like decades of OOP thought them (and many of their educators). Most naive useEffects are just masked derived state.

> It makes purely functional frameworks like modern react much easier to deal with.

But hooks aren't pure functions. They aren't referentially transparent and have an implicit dependency on call order. Likewise, React components aren't "functional" the second you use any of these APIs which subscribe to effects, state, context, whatever coming from elsewhere. React is simply not a "pure functional" enterprise and it's strange to represent it as simply a "violation of some theoretical principles." Those principles are the entire basis of what constitutes functional programming, which is why the original parent described this as not-functional not-oo.

Reply on news.ycombinator.com