5 ms·
> it’s not clear/an easily understandable mental model for most people That's already the case, thanks to hooks. Hooks are weird, and should not be taught to j
by breadwinner 3y ago
> it’s not clear/an easily understandable mental model for most people
That's already the case, thanks to hooks. Hooks are weird, and should not be taught to junior programmers because it will confuse them for the rest of their careers. Hooks are weird because it doesn't align with functional programming paradigm or with OOP paradigm... it is a new paradigm and it is like nothing else.
More on that: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
- andix 3y agoI totally disagree. React hooks are one the best things ever invented.
- notpachet 3y ago> one the best things ever invented Fire? The wheel? Penicillin? Maybe it's just because I'm getting older, but I'm increasingly annoyed when people use these sorts of over-the-top hyperboles.
- andix 3y agoOne 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.
- notpachet 3y ago> 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.
- ervine 3y agoYeah that's a great point. Nothing makes me start really looking closely at a merge request than when a useEffect shows up.
- andix 3y agoMy 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.
- charlotte-fyi 3y ago> 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.
- ervine 3y agoI'll never understand the "hooks are bad" people. I don't find useEffect confusing, creating custom hooks is a breeze, life is so much better than old class components. When I read complaints about hooks I'm either missing something fundamental about why they're bad, or the people complaining are missing it.
- artdigital 3y agoYeah I never found them difficult and they’re making my life so much easier Curious what specifically about them is difficult or hard to understand?
- danielvaughn 3y agoSome people find the mental model to be very confusing. I've been writing hooks for years so intuitively, the behavior has sunk in. But I still admit that it's mind bending to try and understand how it actually works. The original commenter is absolutely correct that it diverges from both functional and OOP, and while that's not necessarily a bad thing, it's reasonable for people to consider it a net negative.
- coolThingsFirst 3y agoWhats the beat resource for the mental model?
- danielvaughn 3y agoThere was an article I read, maybe 3-ish years ago, that explained it very well. It had you actually build a hook from scratch (not a custom hook, like actually implementing hook-like behavior into JavaScript). It was great. I just tried looking it up but couldn't find it, if anyone knows what I'm talking about please link here.
- WirelessGigabit 3y agoFollowing in care you remember / find it.
- ok_dad 3y agoHooks are a new paradigm? That’s news to me, hooking is at least as old as two decades when I first started programming. Hooks are, like most programming ideas, hard to understand at first but easier as time passes and you see more of them.
- rmccue 3y agoI agree. Up until Hooks, you could make your own toy React pretty easily if you wanted to - creating a basic, unoptimised version took a few hours. That made the whole system pretty understandable, especially for junior developers - obviously, you'd always pick the battle-hardened, optimised real React for anything serious. Hooks fundamentally altered the contract about the API that React provided, and suddenly magic was popping up everywhere. Thankfully suspense never really caught on, because that was even more magical. I do quite like the developer ergonomics of hooks, but it does make me wonder about whether there was a world in which we could have had both the ergonomics _and_ something less magical. (Aside: that Medium article is available to members only.)
- ervine 3y agoBut all the lifecycle methods were magic that needed to be understood... hooks just let you co-locate related logic in one place instead of scattered across 3 or 4 lifecycle methods.
- rmccue 3y agoI disagree that they were magic - you could build a test renderer for yourself and see pretty easily how they'd work. The system as a whole was understandable, and it fit into an existing mental model: you implement this interface, and React will call your methods. The specifics of how and when it did were part of the system on the other side of the interface. Hooks on the other hand are functions that you call, which implicitly rely on a magic global state and context, and you cannot use them like other JS functions. You can't conditionally call them or change the order of them, because they contain a unique ID based on call order, which is Spooky (and is why React has to build its own ESLint rules to make sure you don't mess it up!). Don't get me wrong - I do think the ergonomics of hooks are a lot better, but I think at least part of that is due to it being a newer iteration of the API.
- scotty79 3y agoHooks are not like functions. They are like imports. They provide your component with piece of functionality. You don't put imports in if-s or for-s. It's as simple as that.
- danpalmer 3y agoI don't think new paradigms are a bad thing, I think the problem with hooks is that they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have. What's sad is that the class-based component system did have those necessary features, it also had a nice distinction between components and their lifecycle and the rest of your code. Now with hooks, everything is React lifecycle code, unless you're really smart about your API boundaries, and in my experience no one makes good re-usable hooks that are nicely isolated from business logic.
- drewcoo 3y ago> they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have I'd call that a pretty good definition of a "design pattern." In this case, it's also magic framework code.
- danpalmer 3y agoHooks are a design pattern, but I disagree that hacks around languages are a definition of a design pattern. What makes you feel they are?
- deleted 3y ago[deleted]