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-w...
When I read complaints about hooks I'm either missing something fundamental about why they're bad, or the people complaining are missing it.
For accessing browser apis useEffects are the way to go, but those are usually extremely easy to understand in my experience. Or just use a library that provides the needed functionality.
> useSyncExternalStore is intended to be used by libraries, not application code.
https://react.dev/blog/2022/03/29/react-v18#usesyncexternals...
Cause you're inevitably gonna want to track loading state, error state, refetch on error, revalidate etc etc.
swr or tanstack-query are great and remove the need for useEffects for API requests. For sure they come with their own overhead, but there isn't getting away from the complexity of handling API requests and all the possible paths that can happen.
No. Wtf? Don't do that. Never do that. Effects are for legacy DOM manipulation (and ad-hoc use of browser apis). Pretty much nothing else. Who tampers with states and data in useEffect is hellbent on creating spaghetti.
Can't really fault developers for falling into this useEffect trap when even the official docs show that data fetching is indeed handled via useEffect[1], while at the same trying to yell at the reader to "NOT TRY THIS AT HOME" and just go use a framework because it's such a complex problem... which naturally just creates more questions than answers for the poor developer trying to understand how it all works.
[1] https://react.dev/learn/you-might-not-need-an-effect#fetchin...
There are so many things about syncing data between the client and the server that this section of the docs should just say "Don't", use Apollo or Redux or whetever. React is UI library, for data you need data library or at least general state handling library. Quick and dirty will bite you tenfold.
The companies I've worked with had hundreds of engineers contributing to the react codebases and people are just trying to crank out features by the deadline. I'd rather just work with tools that don't require the usage of such obvious footguns. You can code solid-js and svelte and never use effects (even though they do offer them unfortunately).
This is the how the majority of tech companies operate.
> but I know better than to single out the tool for every judgment on design.
I disagree, most react developers are not even aware of this massive foot gun. I do blame tools for problems that are completely avoided by other tools, we can just consider this a difference in philosophy but I prefer to use tools that make as many types of mistakes impossible as they can.
Hooks enable complex patterns too easily and I think this causes a lot of breakdown in what would otherwise be simple applications.
its overuse makes it evident that hooks (or React in general) is poorly understood
Curious what specifically about them is difficult or hard to understand?
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.)
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.
You don't put imports in if-s or for-s. It's as simple as that.
There’s not necessarily bad reasons for this, but the cognitive overhead of this is relatively high compared to existing language functionality.
They use subset of function syntax to provide unique functionality. That's all.
JS was full of such things already. Functions that are hooks (in traditional sense of the word) into some platform provided functionality. setTimeout(), fetch api, promise chains, jquery. You could say that all of those are just functions but you still need to learn what each does separately to get behavior you want. JS is not Lisp where a function means just one thing used always the same way with same restrictions. JS uses functions to construct idioms that introduce functionalities foreign to the core language. React hooks are just one such idiom. You may still argue that introducing yet another idiom is unnecessary burden. I personally like them very much. Component classes were imho very bad conceptual fit for react with a lot of intricate lifecycle methods and special fields. Hooks allow to simplify the core of it to just render that just runs every time it's necessary into which you are bringing in additional functionalities as needed.
Lisp uses dynamic binding for that.
(defun do-something ()
(funcall *something-to-call*))
(let ((*something-to-call* 'turn-the-light-on))
(do-something))
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.
I'd call that a pretty good definition of a "design pattern."
In this case, it's also magic framework code.
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.
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.
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.
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.
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.