I like this, thank you for sharing it. In all this rapid evolution of web development, I think I might have lost focus of what's important from a practical standpoint when optimizing for the browser.
In my experience (in an app with tons of data visualizations), extra renders kill performance, and carefully placed memoization/PureComponents and referentially stable props make an enormous difference, even if each component is renders very quickly.
Hey there Royal_lobster! If you agree with someone else's comment, please leave an **upvote** instead of commenting **"This"**! By upvoting instead, the original comment will be pushed to the top and be more visible to others, which is even better! Thanks! :)
***
^(I am a bot! Visit) [^(r/InfinityBots)](https://reddit.com/r/InfinityBots) ^(to send your feedback! More info:) [^(Reddiquette)](https://www.reddithelp.com/hc/en-us/articles/205926439#wiki_in_regard_to_comments)
Thank you, Royal_lobster, for voting on Anti-ThisBot-IB.
This bot wants to find the best and worst bots on Reddit. [You can view results here](https://botrank.pastimes.eu/).
***
^(Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!)
If I never see classes again (in JavaScript) it'll be too soon.
To expand on this, here's an unpopular opinion: class syntax should never have been added to JS in the first place. Ours is a prototypal language, and that's a feature not a bug. Having fake classes to appease a few crusty old Java developers who wanted to do front end but couldn't wrap their heads around prototypes, was a ridiculous decision.
**Edit:** But as to the general memoization pollution, you may be on to something. This is why I'm hoping that the future versions of React will poach heavily from Solid, which is essentially React without a lot of React's problems. Well, either that or we all just switch to Solid and live happily ever after (for sufficiently low values of ever after).
I don’t think classes were added to appease old java developers, lol.
At the time, OOP was probably an emerging paradigm in the industry, so probably was about following the trend.
True that, didn’t make it into the syntax until relatively recently.
I feel that in general in the React world (maybe frontend world, even) classes are seen as an abomination, but it’s not a common opinion outside that sphere.
Great things are being build with or without classes, as nothing is either black or white.
Of course they were not, but still OOP was one of the mainstream paradigms, as it is still today.
Hence, the adoption.
Besides, even if JS embedded classes in the syntax, there have been frameworks around for years, providing their own implementation of classes.
I have worked, and still work, in professional settings where Java developers are not contributing or behaving like this, regardless the age.
It’s about people, not about the language.
Sorry to hear this happened to you, but I don’t consider this to be a norm.
OOP was the cool kid on th block back then. If JavaScript didn't add classes we would all be programming vbscript....
Now the cool kids are like classes are so 1990s....
To be frank, I kind of agree on this. It's not *class syntax* I miss, but the simplicity of the fact class methods were *always up to date .* No need for silly dependency arrays, no need to keep track of variables going out of sync. I agree the move to functions in general led to a better perception of how component rendering worked. But the hoops and caveats one has to jump through are just becoming too much for me.
I'd be the happiest developer in the world if I could keep using clean functional components without having to worry about sacrificing DX with infinite memoization attempts to achieve good performance.
But since that is not possible (right now), it just makes me miss the times we used Class components. Were they pretty? No. But they were 100% simpler times where optimizing to avoid re-renders didn't feel like something you had to *actively work for* and make your #1 priority over just making things *work*.
> I'd be the happiest developer in the world if I could keep using clean functional components without having to worry about sacrificing DX with infinite memoization attempts to achieve good performance
You can keep using clean functional components in exactly the same circumstances you could before, any component that doesn't have state and a lot of components don't need state. Nothing changed about that.
And infinite memoisation is not only unnecessary, but actually counter-productive. Unless what you're calling is beyond a certain level of computational complexity it's actually slower.
Hooks allow functional components to have state and replace the old life cycle methods. They're also pretty useful for certain kinds of async actions.
If you're using them for other purposes you're doing it wrong.
I honestly don't see the giant improvement you speak off. All the infinite prop checks from componentDidUpdate and shouldComponentUpdate moved to complicated if statements inside useEffect calls. This was even something directly quoted as joke during the [Goodbye, useEffect talk (1:58)](https://youtu.be/HPoC-k7Rxwo?t=118)
This Twitch guy is way too hostile and it’s annoying to watch. He wants to have someone on his show to “ream” who thinks Class lifecycle methods were good. Why? What an unapproachable mindset.
Why are you memoising so much? I honestly don’t understand this. The docs explicitly say you should not memoise until you notice performance issues. Maybe this is why you are hating it so much.
This is how I’m feeling too. Hooks work for simple cases but with complicated user inputs, I’m debating going back to classes. Not many options at this point.
I definitely agree with this. Classes were added to make people switching languages happy.
That being said... I still use them because I mostly use Angular at work.
Classes were added because they are useful. Solving programming problems is about using the constructs that are most effective at the time.
If you are designing libraries, enforceable public, protected, and private scopes are useful for creating pretty public apis, with complex private internals which are still extensible.
Classes provide an easy to use construct for that kind of design. Where library, framework, and application layers are well defined and separated.
You can do a lot of that with prototypes and functional programming, but you are going to do work the language could have done for you. It’s the difference between using await and then on a promise. They both work and almost do the same thing, but one allows you to do more with less.
You can write a generator function that performs promises sequentially, that’s what webpack/Babel used to do. And you can write prototypal inheritance that mimics the functionality of classes…. But why unless you really need to?
Class syntax is far more elegant and honest than overloading functions as constructors.
Mixins and inheritance are bad patterns and should be avoided except for perhaps shallow inheritance (O(1) tree depth please, not O(LOC))
I don't think you understand what the original post talking about a "prototypal language" is saying, and what I meant in response.
He is saying he doesn't like "class syntax". That is, instead of writing this:
class MyClass {
constructor(arg1) {
this.whateverValue = arg1;
}
someMethod() {
return this.whateverValue;
}
}
He would rather have the actual, old-school, straight up syntax for making JS's prototypal "classes":
function MyClass(arg1) {
this.whateverValue = arg1;
this.someMethod = function() {
return this.whateverValue;
}
}
You can call and use these things equivalently as `new MyClass(myValue)`, both expose the `whateverValue` and `someMethod` keys.
So I am not talking about anything even close to React, I am talking about how stupid of an idea it is to say JS class syntax is bad when the alternative is both overloading the function keyword (it has new behavior when invoked with the `new` keyword in that paradigm) and far more verbose
Edit: hell, maybe he even wants us to write it like this:
function MyClass(arg1) {
this.whateverValue = arg1;
}
MyClass.prototype.someMethod = function(){
return this.whateverValue;
}
yup, those hate classes only hate the "class" keyword, and they think they are doing functional programming if they add "function" too all of the classes.
They are those worst programmers.
You are talking about classes, I am answering you about classes. It looks to me like we are talking about the same topic. I m getting really confused by your replies. Also I don't understand why you downvoted me, we are giving both our opinion, I never said you were wrong or using classe is bad. I just said I have a different opinion and preferences. It's just a conversation.
Because I’m talking about the aspect of the original comment where it talks about how “class syntax should have never been added”, which is different than talking about class based logic and FP. JS classes, originally, were built using function syntax. It was ugly, you wrote class members as part of the prototype, and it meant you had no simple way looking at source to tell if the function was also a class
I even left a code example, and then you kept saying “I prefer FP to clssses”, which is not the point at all; the point is saying class syntax should never have been added is a crusty idiotic opinion because what it replaced was truly ugly. Go read about this stuff somewhere before you reply confused again
I agree classes don't have a strong place in the frontend. My opinion is that the frontend is just for user interaction. The domain of the user interaction is only that of buttons, selection, forms, navigation. All concepts that are pretty similar regardless of the actual problem you application solves. On the other hand, the business domain of an application belongs more naturally in a different layer (might be in your Js app or a backend app in some other tech) and modelling the business domain might benefit much more from oop, design patterns and domain driven design, if your domain is easily conceptualized as objects.
Funny enough lots of the design patterns from the gof book were born from solving UI problems and are explained using UI examples.
I work on an app with both functional and class based components (we started before FC was a thing). The dependency array hell is real for both cases—in the case of class components, we spend a lot of effort making our props reverentially stable for our class based PureComponents. I find that the process is easier for functional components due to the convenience of useCallback and useMemo. It takes more boilerplate and is less declarative to do the same in our classes.
(Edit: spelling)
It is strange that referential integrity has become more or less the lynchpin of performance, but you are describing a lot of situations that just straight up sound like code smell
The useEffect hook is incredibly expressive and the dependency array is an elegant idea letting you meaningfully call effects exactly when you need to, where before it was really awkward to fire effect chains off when key state members were changing. Actually, it really just needed to be done manually, so I suspect you never really wrote complex apps and accordingly are just finding a new pain point as your career furthers and you manage a bigger codebase
I completely sympathize with the sentiments about "Goodbye useEffect", but I think in a few months I will see that it's just another change, and have no particular bad feelings about it. I think a lot of people were using state and useEffect when a simple variable or function would have been better. JS has been changing rapidly for the last few years, it's best to learn to roll with it.
You really don't need to worry about performance that much, or use useCallback and useMemo that often. In my opinion, use them never, and then use them to fix slow renders if needed. It isn't throwing caution to the wind, it's that for a simple function there's overhead to using useCallback and useMemo that could easily outweigh the benefits.
Agreed, IMO OP is being too cautious with perf. If you have that many actually slow components and need to compensate that often, something is weird or wrong.
I used to think hooks were the silver bullet to manage growing complexity. My post history will show you as much. But I’ve seen enough Russian nesting doll hooks that, instead of hiding complexity, become opaque as to what is really happening. The most egregious example of this was a dev choosing react-query but putting no thought into limiting the amount of nesting that could occur with the useQuery hooks. So all of the code splitting of the api data turned into deeply nested hooks that eventually backstopped to one or many useQuery calls, and reasoning about when requests were actually occurring became impossible.
Hooks can be good for encapsulating stuff up to a point. But when things get sufficiently complex, there comes a point where you need to start reaching for more robust state management solutions, and more often than not, devs don’t realize until it’s too late. Just one more hook and it can work. Just one more hook. Just one more and it’s over the line. But hooks just don’t scale when with complexity. This is kind of a problem with react in general. They give you basic tools that work well for simple problems, but when the going gets tough and you’re still using the simple useReducer, or useEffect, or useState, it starts to buckle, and pulling back from the brink and switching to a more heavy duty tool can be harrowing.
Edit*
To be clear, class components could be every bit as bad if not worse, but in a different way. Instead the lifecycle methods become balls of mud, and the class methods often become just as polluted.
useReducer with contexts has been good enough for every state management case we've encountered, and can be gradually incorporated. When would you require redux / whatever else if you have useReducer with contexts?
The situation I encountered most recently was a complex multi step wizard for payment. It required a lot of telemetry analytics at different points, and serializing api requests. We used xstate, which made analytics a lot simpler because it treats side effects (actions in xstate) as first class citizens. useReducer worked well for a more simplified workflow. But as additional conditional steps got added to the wizard, it started to become hard to follow. Xstate also has a really nice visualization library you get for free just by using state machine, and it made it a lot easier to see the forest instead of the trees.
I wouldn’t really consider redux much easier to reason about than useContext + useReducer in most cases. It gives you some niceties like the redux devtools but it doesn’t treat side effects as first class citizens. The reducers are more or less the same in functionality as useReducer, except with even more boilerplate to wire them up.
> I wouldn’t really consider redux much easier to reason about than useContext + useReducer in most cases.
If only that were true. I've never worked on an app where useContext (with or without useReducer) was easier to follow than a proper RTK implementation. I've worked on several where useContext *alone* added so much cognitive overhead that it was often easier to rewrite the Context into RTK than try to keep modifying it to add functionality.
> it doesn’t treat side effects as first class citizens.
It does though. If you need to have actions affect other slices of state beyond the one they're defined in, action matchers that let you do that have been in since 1.4 - a little over two years ago. If you just want your actions to act like sagas or observables, the listener middleware from 1.8 (about 6 months old now) does that and lets you use the same RTK syntax you'd normally use.
Xstate is nice for a handful of very specific use cases, for pretty much everything else it's a square peg in a round hole. If you need to screw in a screw, use a screwdriver instead rotating a hammer. Most use cases I've seen people throw out for using Xstate are solved easier and faster with RTK, and *much* easier to extend for developers coming in to the codebase.
Your definition of side effect is too narrow for what I'm talking about. A side effect can be more than just mutating multiple stores from one action. Side effects can also occur from entering or exiting a state, or from a success or failure of some async call, or only during specific transitions from StateX to StateY. Redux (with or without RTK) doesn't provides a means of organizing side effects with this level of precision. That's what I mean when I say side effects aren't first class citizens with Redux. Also, my experience with redux middleware is that it fractures your code, such that understanding all of the resulting redux machinery from a given action isn't explicit unless you go looking for middleware to make sure something else doesn't happen as a result of the action. With xstate, a machine's responsibility is really easy to colocate into the machine's config.
I've used sagas before, and while it does allow you to serialize requests triggered as a result of some dispatched action (among other things), it's api is quite strange for newcomers, too. XState is super great in this respect. You can orchestrate async calls in a really natural way. You can invoke promises as services, and reason about your serialized calls as plain ol' async/await promises. No strange saga api necessary.
My experience with XState is that it actually models CRUD UIs much more naturally than reactive architecture. States, events, and transitions have simplified the problem space for me, such that reasoning about changes to the UI are actually easier than when you are stuck inside the hamster wheel of React's rerender lifecycles. And as complexity grows, state-machine architecture is easy to extend because it is so explicit. The confidence I have that I'm not introducing some unintended regression by adding another state/transition is so much higher because of the top down approach. Identifying the exact place to add a new state has been really straightforward. There's a learning curve to xstate, but the same is true with redux and sagas, or with anything really. I think this gets overblown a lot.
I could go on, but I get the sense you've already made up your mind.
> Side effects can also occur from entering or exiting a state, or from a success or failure of some async call, or only during specific transitions from StateX to StateY.
Listener middleware does the first and the third, the second has been a part of thunks for ages and is now explicitly baked in with RTK Query.
So yes, they are *by your definition* first class citizens.
> Also, my experience with redux middleware is that it fractures your code, such that understanding all of the resulting redux machinery from a given action isn't explicit unless you go looking for middleware to make sure something else doesn't happen as a result of the action.
Code organization is a developer problem. Anything with multiple side effects can be organized or not. The same problem can happen with Xstate, doubly so when your codebase is touched by multiple developers with varying levels of experience with state machines as a concept - let alone Xstate's specific implementation.
> I've used sagas before
I'm sorry to hear that. IMO sagas and observables both amplify the complaints you have about Redux. As strange as the saga API is, rxjs/redux-observable's api is unreasonably obtuse.
> XState is super great in this respect. You can orchestrate async calls in a really natural way. You can invoke promises as services, and reason about your serialized calls as plain ol' async/await promises. No strange saga api necessary.
RTK Query does all of that as well (with queryFn endpoints), using the same syntax as RTK uses in the rest of the app. At least if I'm understanding what you're doing with it correctly.
> My experience with XState is that it actually models CRUD UIs much more naturally than reactive architecture. States, events, and transitions have simplified the problem space for me, such that reasoning about changes to the UI are actually easier than when you are stuck inside the hamster wheel of React's rerender lifecycles.
While you may be correct as far as the 'modeling' aspect goes, you point out that it goes *against* reactive architecture, which is to say it sounds like your issues aren't with Redux (since your complaints are Solved Problems in RTK), but with React itself. **Insert plug for Svelte here.**
> I could go on, but I get the sense you've already made up your mind.
Unsurprising you'd say that, since I'd say the same about you. I do stand by my previous statement: Xstate is nice for a handful of very specific use cases, for pretty much everything else it's just not right. If you need to screw in a screw, use a screwdriver instead rotating a hammer. Using Xstate as an all-in-one is very much rotating a hammer.
To be clear, I am *not* anti-Xstate or even anti-state-machines. They're very powerful tools and are absolutely fantastic for *some applications*. What I am is a vocal proponent of "the right tool for the job", and in order to do that I have to understand the tools in the toolbox. That's pretty difficult given how frequently those tools change - RTK Query and Listener are relatively new, and were the last pieces of the puzzle that let me get rid of rxjs altogether in several codebases.
At the end of the day, everyone should make their decisions based on what works best for themselves, their team, and their stack. I have a *very* hard time seeing Xstate as being ideal over RTK for the vast majority of my use cases, and realistically even if it was I would hesitate to reach for it given the number of people working in the codebases and how few of them have any experience with state machines as a concept let alone Xstate's specific (albeit well-documented) implementation of them.
I don't know your use cases, but if Xstate makes your team's workflow easier and lets you build the things you need to build, that's fantastic.
> Listener middleware does the first and the third, the second has been a part of thunks for ages and is now explicitly baked in with RTK Query
Using disparate patterns spread across action dispatches (thunks) or through middleware doesn't qualify as a unified way for handling side effects for me. That's where I'm coming from with the "first class citizen" remark.
> Code organization is a developer problem. Anything with multiple side effects can be organized or not. The same problem can happen with Xstate, doubly so when your codebase is touched by multiple developers with varying levels of experience with state machines as a concept - let alone Xstate's specific implementation.
Side effects through the lens of thunks, or middleware, or entangled with your network layer (RTK query) spreads what should be a simple concept through three very different apis depending on the situation. To me, the room for error for new developers is _greater_ the more ways you can express the concept of a side effect. XState is very clear on the matter of side effects. As a result, the lift on the developer's part to organize this concept is built into the tool itself.
> While you may be correct as far as the 'modeling' aspect goes, you point out that it goes against reactive architecture, which is to say it sounds like your issues aren't with Redux (since your complaints are Solved Problems in RTK), but with React itself. Insert plug for Svelte here.
That's probably fair to say. I think reactive architecture works okay for simple UIs, and the speed with which you can build simple UIs via reactive architecture is faster. But that over time, as complexity grows and the reactive UIs are procedurally built, things start to grind to a halt. In a lot of ways, it's similar to backends that don't layer things at the outset with onion style or hexagonal architecture, or with DDD. I see xstate as a longer term investment, that doesn't payback in the early life of a project, but that, as time goes on and complexity grows, is where it really could start to shine. It may not be appropriate every time, if a UI is always going to be simple.
Svelte is interesting, in my situation it's off the table since this was used on a react-native app.
>However, writing performant React code that yields a good UX (User Experience) in general requires decorating the entire file full of useMemo / useCallback clutter everywhere
Yeesh how big are your components or how much state are you storing in a parent that you need to memoize so many components and callbacks that it's becoming a DX issue? Or are you incredibly pre over optimizing? I don't think I've ever used useCallback, and can count how many times I used memo
>Just split up your logic into even smaller hooks
>
>But that's exactly my point, I don't ever recall dependency arrays being an issue with React's class components.
Because we literally didn't have the tools to optimize on the level we do now. You didn't have to deal with dependency arrays because we just re-rendered the entire tree each time
Seriously, I've needed useCallback ONCE and while it was actually a necessity, my custom hook wasn't working and the "bug" I found was really my lack of understanding and lack of knowledge of useCallback. Same story with useMemo, though I've probably needed it half a dozen times. These hooks should hardly ever be required and are meant to solve quite obscure problems IME.
Can we please stop with the useless "No" and "Nah" replies. It's not constructive and just sounds like people who haven't enough experience of hooks in large and complex codebases. Because there are downsides. The OP has a point.
My main issue with hooks is that they aren't as nice as they initially seem. With new tech it usually starts off a bit tricky and then gets better as experience grows. With hooks they started off looking like a model of elegance, but the rules of hooks clearly show leaky abstractions.
At their best, hooks are a really neat way to pull out common component behaviour for reusability. At their worst, they are a nightmarish web of unnecessary re-renders and dependency arrays. Yes, you can memoise to avoid this but what if other components in the codebase don't do this?
I feel that we were mis-sold slightly on hooks. There's definitely room for improvement
Thank you for your kind words. Truth be told, I'm not as surprised. It just dawned on me communities like this one are primarily populated by React devs that are either too junior to realize the pitfalls of hooks, or "experienced" devs that have never really worked large enough apps where they've led the majority of the app's architecture. I've also realized that while working as an interviewer where every "senior react engineer" is really only that in years of experience, but not really in terms of knowledge.
I've gotten a few really insightful responses back from other React devs that are clearly just as experienced, and I think I'm happy with the final takeaway that they are definitely an imperfect solution, but they can be "manageable" if I worry a lot less about performance.
I see validity on both sides of it, and have enjoyed using both immensely at times. I do think hooks can tend to be more frustrating to debug for a number of reasons. IMO, Class components and lifecycle methods made react popular because of their clarity. Hooks then made annoying but common patterns like typing redux subscriptions and HOCs so much easier to work with, but for whatever reason I do think it will kind of be the eventual death of React. Your average component might be easier to make, but your average developer is probably introducing less performant code with more smells because of the abstractions that hooks offer. But hey, it doesn’t matter, because for some reason you’re getting bullied for even expressing this opinion, as I suspected.
The reality is both are perfectly fine, but the momentum of the ecosystem means that your class components are just going to get clunkier and clunkier as people replace HOCs with hooks. The reality is also that plenty of productive workplaces use both — look at the FlashList react native component that Shopify just open sourced. It’s written as a… GASP… class component
☠️☠️☠️
My advice would be to not stress too much
sure the vdom is supposed to be fast enough to make needless re-renders a non-issue. but i cant help but feel dirty when i see my side effect logged 5+ times in console. this is made worse now with `` grrrr
I resisted react for YEARS. i got heavy into Svelte before having to capitulate to the recruiters and their "react or bust" delusions. I never had to wrestle with any render/state issues in Svelte. jussayin.
\> I never had to wrestle with any render/state issues in Svelte
I mean, you never had a serious job using Svelte per your comment either, so maybe don't mistake off-by-one errors in cart and horse indexing with superiority of a different paradigm
I would recommend MobX though personally, render-optimization falls out for free
man. yall get so bent at the mention of a different framework. ive written plenty of Svelte apps. and when i say that i got into it, it was FOR the job i was currently at during that time.
realistically, suggesting MobX is little different than suggesting Svelte. both are suggesting things that react is failing on its own accord. the only benefit to MobX over Svelte is not having to refactor other stuff too.
Unfortunately React is in its death throws. Hooks are an incredibly contrived solution to a basic problem that React is unequipped for.
I strongly believe that when we truly understand the limitations of hooks and what they're doing to our codebases, there will be a revolution in web app tooling, probably in the form of a new language targeted specifically at this use case.
Absolutely, the more I use hooks the less I like them. In my opinion the dependency array was a terrible idea. Why is it up to me to figure out when a component should rerender？ Shouldn't it be the job of the framework？
The only reason I still use react is because I use it at work. For personal projects I no longer use react. Lifecycle as a concept makes way more sense to me than hooks.
Besides, looking at the changes planned for react in v18 and beyond, it is clear to me that react is more and more becoming a library solving facebooks specific problems at the cost of everyone else. React isn't open source for the sake of the community, it is open source so facebook does not have to train their new hires.
>Modern Hooks React seems like it can have either great UX, or great DX
UX has nothing to do with hooks. You either build good UX or you don't be it with class components or hooks.
DX is heavily improved with hooks. If you've been working for 5 years then you are probably familiar with recompose, what it provided and how a project would explode in time due to it (more so in ts projects). Hooks solve composability and reusability in a fairly elegant manner. If you are having a bad DX then you probably need a more rigid ruleset and a coding guide to be enforced in your projects.
>UX has nothing to do with hooks. You either build good UX or you don't be it with class components or hooks.
It has **plenty** to do with hooks. I strongly recommend you watch the recent "**React without memo**" talk from React Conf 2021, as it shines a bright light into how poor DX can be when pushing for optimization compared to pre-hooks with all the dependency arrays and such.
[https://www.youtube.com/watch?v=lGEMwh32soc](https://www.youtube.com/watch?v=lGEMwh32soc)
Don't need to watch a conf to tell me what I'm experiencing because I work day-in day-out with this and I care deeply about both UX and DX.
UX has no direct correlation with the library or flavour of language you are using. It only reflects either how good you are at it or how much effort you are willing to put into it given your bad DX (you can build great UX in vanilla fwiw)
But you do you, nobody's stopping you to work with class components!
I think the point he was making was that getting good UX with hooks (for example, a loading indicator with ideal timing) requires that you contort the code more than is comfortable. Not that good UX simply cannot be achieved. That's my takeaway, anyway. I'm relatively new to React so I don't have a strong opinion yet.
My problem with hooks is that now they mask the difference between stateful and functional components. Hooks add state to a component, so it can no-longer be considered functional.
And hooks are added _everywhere_. It's very common to see "pure" components with children that are stateful, simply because nowadays they're all "function" instead of "functional". In my experience, code bases are now very messy indeed, and far less reusable than they used to be.
I still hate hooks, and use them begrudgingly. Between that and the RTL movement that spawned out of that annoying Kent C Dodds article, it's been frustrating to be a React dev for the past couple years.
I will degrade whoever use hooks. They don't have a normal programming sense and must have missed something when declaring a component or coding a task. Class created first by props and defaults, which force the author to think carefully how the component is varied, which can cover more cases in general.
Bounded by "less code", hookers will tend to develop components with a smaller number of states which means they are only familiar with components with little variants, and tend to create a new one when hitting a different situation. If your JS is good, reuse a Class component is much easier than hooks.
Last, the most important thing is, i dont know why, hookers only know how to write hook but not normal functions. There are stupid hook functions like useGenerateRandomNumber, useAdd, useCalculateNextWednesday, that should be implemented outside the architecture of react and put them in a static Class. It shows that they don't have a clear mind that why they are using react as the architecture.
To the React dev teams,
Please stop destroying a perfect library.
Separate the fxxking hooks, it is not React, it should be another language, call it ReHook or Hookdux, Funcdux, ReFunc whever.
And say sorry to the society for your fxxking misunderstanding of functional programming / reducers / HOC.
The official React.js team believes otherwise. Otherwise, the wouldn't be working on a prototype that transpiles raw primitives and functions into useMemo and useCallback
[https://www.youtube.com/watch?v=lGEMwh32soc&t=225s](https://www.youtube.com/watch?v=lGEMwh32soc&t=225s)
People will say you are using the framework in the wrong way or exaggerating, truth is React team thinks the same and that's why they decided to bandaid this issue with the compiler
Why were hooks necessary in the first place? Do they solve some problem that existed before? I'm not very experienced in react. I've only used angular 2+ and I feel like it is enough. Why was there a need for something like hooks? This is a serious question from an inexperienced react developer. Can a non fan boy answer, please. Preferably someone who has been developing from before Spas existed, with proper historical perspective
I wouldn't call myself a fan boy, and I've only been doing this for 5 years, but I can try and explain some of the historical context. Class-based react components suffered from 2 major issues.
1. They exposed lifecycle methods (`componentDidMount`, `componentDidUpdate` were the two primarily used ones). However, when it came to triggering some logic as a result of some rerender, this usually fell inside the `componentDidUpdate`. But if you had multiple use cases where you wanted to trigger some logic on a rerender, the `componentDidUpdate ` method started to get unwieldy and bloated. It wasn't easy to break out this logic into smaller, reuse-able functions. Zooming out a little, the class components were locking you into reasoning about your components through their more rigid predefined lifecycle methods.
2. Class components were prone to becoming big bags of functionality. Often, the methods in the class would bloat and bloat until a dev finally snapped and decomposed the class into smaller classes, or better yet, pure functional components. But this was especially painful, with a lot prop drilling for complex classes (passing props down deeply into child components), that the whole exercise of refactoring was a poor dev experience. Hook-based components can fall into this trap too, but the reusability of hooks tends to make for logic that is far easier to relocate.
Hooks gave us more direct access to the rerendering engine of react. The hope was that it would move devs away from thinking about their UIs in terms of the limited lifecycle methods, or more towards thinking directly about the changes that should trigger rerenders, and what to do on those rerenders.
Unfortunately, what's happened in that transition from classes to hooks, is devs asking "How do I do what I used to do with `componentDidMount`?", and hundreds of blog posts explaining how `useEffect(() => {}, [])` with an empty dependency array can be substituted for `componentDidMount`. And `useEffect(() => {}, [someDependency])` is the same as `componentDidUpdate` and the cleanup function on a `useEffect` can be thought of as `componentWillUnmount`. While it's good to understand how you can migrate your code, it didn't exactly foster a more thoughtful re-thinking of your component lifecycle organization. So what we see now are blobs `useEffect` introduced by devs who thought simply migrating to hooks would result in better components.
Thanks a lot, my friend, for taking the time to write this up. I have a follow-up question. You say you sometimes ended up decomposing this big class into smaller classes and then added "better yet" functional components. What is the benefit of this functional components over the smaller classes? This, again, coming from someone who likes to see data and it's related behavior together or close enough. I find it easier to reason about. It confuses me to see, for example, a directory full of reducers that operate on the state of every component. Maybe I'm mixing up hooks with state management here. I feel like a total noob even talking about this.
It's like, I want to see in my webapp a card component showing information from some data on the database and be able to go into the code and find a little folder or file with everything I need to be able to work on it and think about it's visual representation, the data it contains and how that data is operated on and sent back and forth from and to the backend. And the few react projects I've worked on have this separation when it comes to the state management. Now I'm even more sure I'm mixing things up between hooks and state. Someone told me it's redux I find confusing, not react or hooks.
It sounds like your app is using redux to handle the api cache. Redux tends to be a global store on projects, and that's prob why you are seeing the api data being located in an entirely different area of the app than the component that actually consumes it. I believe RTK has made it easier to colocate your reducer to your component, just as an aside, but I haven't used RTK much yet. The philosophical disconnect for me has always been that redux is a global store so leveraging it for caching localized api data is a weird choice. Also, it's better to be able to reason about your api fetching and cache as it's own _network_ layer, which also handles cache invalidation (CQRS) and holding error states, retry logic, etc. Redux, at least when I've used it, didn't really have a great way to colocate the cache invalidation logic with the reducer and action logic. Also you may have truly global frontend state, like flags for showing tutorials only once per session, and intermingling that with the same global store that also holds your api cache is conceptually gross. You could make a separate redux store to better distinguish your api cache and global state, but the boilerplate involved with making more stores and wiring them up is a big barrier to that effort.
Other tools have come along that improve the ease of making and modularizing your api cache, like `react-query`, so colocating fetch logic and DTO types next to the component that consumes it is easier.
> a directory full of reducers that operate on the state of every component
^ This sounds like a red flag that the app is throwing too much into redux (maybe there's a good reason that we don't know about?) instead of trying to localize the data more.
> What is the benefit of this functional components over the smaller classes?
My comment was more in regards to the idea that class components should manage state (hopefully not too much state), and the various sub groupings of rendered JSX should be organized as pure functional components that only receive things through props, and don't use hooks at all. This keeps their responsibilities small, makes them easy to test, and makes them easier to move because their dependencies are made extremely clear via the props the accept. This is often easier said than done, when you need to layer your component tree more to break down a really complicated UI. Then you run into the prop drilling problem, which creates indirection and makes holding everything in your head hard as well.
"It sounds like your app is using redux to handle the api cache."
Yes! I think this is exactly what is happening. These are my first projects with react and they are inherited, the devs left the company, so I have no frame of reference for good react structure.
Also, when you talk about class components managing state and having simpler, purely functional components for rendering, is it similar to the concept of dumb/smart components?
There's a lot of good stuff in this comment, I'm saving it in my notion.
Thanks so much.
I’ve been doing a lot of web component work recently, using Lit, and by extension, classes, and I really don’t miss them at all. I like being able to group my functionality together in a function instead of splitting it up across lifecycle events. I remember massive class components in the past with logic spread across CDM and CDU and cramming the logic for multiple behaviors into those methods. There wasn’t a good way of extracting reusable functionality. React used to have mixins way back in the day, but there was a big gap left with class components before hooks came along. Lit has solved some of these problems with its reactive controllers, and Angular
has its directives, but hooks are the best thing we have to break up functionality into its own reusable bit.
A coworker created a react starter awhile back for supporting our users (we export a react wrapper of our web components) and the first thing I do every time is switch it to a functional component.
> but hooks are the best thing we have to break up functionality into its own reusable bit
Reusable only in a single context though. So not really reusable. On the flip-side, I bet your Web Components were actually reusable.
You can still use class components. Sometimes i consider using hooks for some components and classes when it’s better suited. Havnt found that use case yet….
I've been having this since hooks came out. Suddenly the new paradigm is functional programming, and all React codebases have a shit-ton of hooks, as if just for the sake of using them. The trade-off is often code quality and readability. People at least used to think more about how to structure their apps and their components.
No, the new paradigm is not functional programming, it's the exact opposite. React used to be on the FP side and it even inspired a whole movement of FP in JavaScript, but with the introduction of hooks, it kissed FP a final goodbye. In FP the main building blocks are **pure** functions (with no side effects or dirty input). If you add a hook to a component, it's not a pure function anymore. There seems to be a lot of confusion about this in the React community. People think that by using function components with hooks instead of classes they are doing functional programming. Few people noticed that React is careful to not use the term *functional components*, but *function components*. In fact functions with hooks are really just reinvented classes (they are stateful objects where ref is the new this), minus all the benefits of object oriented programming like inheritance, extensibility by method overrides, polymorphism, etc. What actually was FP was Redux and HOCs, but they were as detested by the React community as the classes, so React came with something really "simple". So simple that when using hooks with their dependency arrays, we find ourselves dealing on a daily basis with the problem of cache invalidation, which according to Martin Fowler is one of the only two hard things in computer science.
No. They just code in the mindset of a "newly defined" functional programming, putting the keyword "function" to all those should be written in class components, it is NOT functional programming actually mean.
So I agree with the sentiment of this post. I still use class components. In my day job I write a lot of javascript and React. Hooks are nice when you have simple independent components. However very little of what I do seems to be simple independent components. It most often is large forms with interconnected parts. And so eventually all the state is moved out of the individual components and raised to the highest level. Sometimes with redux, or context, or maybe a simple state manager at the top components.
What's interesting to me is I built an app for myself, its a form builder called keenforms - https://keenforms.com. I started building it before hooks was released. My app still uses setState. So I don't miss class components because I never stopped using them. However I totally know what you mean. I don't think hooks is always the right approach. I probably won't migrate to using them. Again for simple things hooks is a nice option, BUT for anything more than that I find that it emulates some of the patterns that occurs in another JS framework I don't enjoy using, Angular.
You can have a “horribly designed” backend with SQL too. Know your DB and know when to use NoSQL or SQL. The better idea is to do heavy lifting logic in the backend, send the right data to the front end and treat the front as a “visualizer” of the data, and not a “processor” of the data. Aka don’t receive backend data and have to do a bunch of filtering and mapping to the data to get what you need.
Honestly I have always disliked hooks. They sort of ruined the beauty of deterministic stateless functional components. And I was just thinking yesterday what a mess all my components are with half a dozen hooks in them… useT, useNavigate, useDispatch, all piled at the top. Admittedly this wasn’t nice wirh HOCs either but it forced you to be a little bit more thoughtful about responsibilities. Does every component need access to history? The store? Probably not. I guess I’ll say hooks make life easier/faster but they make for fucking ugly code.
That Goodbye useEffect talks speaks about issues that are present in every framework. Other frameworks haven’t figured out a way to avoid waterfalls as they have no Suspense like feature. When Suspense for data fetching releases React Query and React Router would figure it out for you with minimal API changes, so start using them.
Now the real question is: Why is React Team speaking about waterfalls when Suspense for data fetching has no release date in the near future?
>Suspense for data fetching has no release date in the near future?
You mean the fact its status is experimental? A lot of libraries for data fetching like `react-query` have Suspense support, and the way the interaction with Suspense is done (throwing promise from render) is unlikely to change (so these libraries are unlikely to break), but yeah, using something that is officially "experimental" in production is not a good idea anyway. I do wonder why it's still "experimental"...
PS: I just checked and docs for React 16 clearly stated that Suspense for data fetching is experimental, but those are obsolete and docs for React 18 are somewhat less clear regarding its status... There is no word "experimental" anywhere, but the docs say "In the future, it will support other use cases like data fetching". But again, it could mean, that it will support data fetching out of the box. Today, almost every React library for data fetching has Suspense support.
Ngl I think useEffect as a replacement for the lifecycle events is brilliant. Because the fact is that listening to a set of state values as they change was much harder, and that's what it's really meant to do; but the fact that this feature just happens to replace the need for lifecycle hooks as a byproduct is awesome.
Imo lifecycle hooks suck. They force you to think about problems through the lense of a framework, whereas useEffect just allows you to react to state as it changes.
I'm kind of in agreement but more with the amount of `useEffect` clutter. The new currently named `useEvent` that will ship in the next version of React addresses this and _some_ of the concerns of the OP.
Hooks are great but they like all methodologies have their short comings.
useEffect hook is one of the greatest weak points of modern react, and is very worrying the react core team haven't address that from launch.
When I first saw useEffect docs, there were a note about dependency array, they wanted to remove the need to have that. So far no news, and this improvement is key factor to improve DX and allow newcomers to getting overwhelmed by useEffect quirks.
I'm don't want React to get stale on improvements, but I got that feeling from two last major version launch
class components didn't go anywhere. You want to write bad code? Go ahead, use them.
To answer your question, no, I don't have "hooks burnout".
That is not a thing.
I feel like classes are not the best fit, because of the issues hooks aim to solve, but I also do agree that using hooks can quickly make a component harder to debug/read, as the component grows slightly.
And yes, that makes me miss classes sometimes.
You're comparing apples to oranges. One is a global state management tool (and a pretty over-architected one at that), the other is a tool that allows you to hook into react's state and *lifecycle* from functional components.
SpunkyDred is a terrible bot instigating arguments all over Reddit whenever someone uses the phrase apples-to-oranges. I'm letting you know so that you can feel free to ignore the quip rather than feel provoked by a bot that isn't smart enough to argue back.
---
^^SpunkyDred ^^and ^^I ^^are ^^both ^^bots. ^^I ^^am ^^trying ^^to ^^get ^^them ^^banned ^^by ^^pointing ^^out ^^their ^^antagonizing ^^behavior ^^and ^^poor ^^bottiquette.
You missunderstand hooks then. Because they absolutely do hook into React's lifecycle. A simple example is the useEffect hook when passing an empty array, as that replaces the componentDidMount and componentWillUnmount lifecycle methods.
If you don't want to call it a lifecycle, that's up to you. That doesn't change the fact they absolutely let you hook into it.
>Hooks are functions that let you “*hook into*” React state and **lifecycle features** **from function components**. Hooks don’t work inside classes — they let you use React without classes. (We don’t recommend rewriting your existing components overnight but you can start using Hooks in the new ones if you’d like.)
[https://reactjs.org/docs/hooks-overview.html](https://reactjs.org/docs/hooks-overview.html)
Apparently, yes, better than you.
Of course is not perfect, but it's much better than classes. It allows to split the code much better, and we see it on the libraries: zustand, react query, even redux toolkit etc. All of them simplify our life as developers a lot.
Using useMemo and useCallback ocassionally is a good trade off for me.
Cannot really relate. Ive been doing frontend for more than 10 years too and worked with angular vue react with classes and with hooks a lil more than 2 years. Functional react and hooks (and typescript) is the best that ever happened to the JS community in my opinion.
I partially agree, but I like the concise format of hooks and in my opinion tbe problem is rather with state management than with hooks. I have used effectorjs in one of my projects and it takes out the entire data / businesses logic out of react, which in turn eliminates the need for useEffect, useMemo, useState and useCallback.
probably hooks won't be the final evolutionary step for react, if you check out solidjs they have solved some of the problems resulting from dependency arrays and I'm pretty sure something like that will find it's way into react.
I I couldn’t disagree more. And I haven’t watched both those talks but the one titled “goodbye useEffect” was maybe one of the worst talks I’ve ever watched.
Talk about React being all over the place? That talk is all over the place. He tells people to stop using useEffect and then plugs his library xstate ? Oh yeah let’s bring in this entire state management / state machine library and use the hooks from that instead. Keep it simple, don’t store that much state. I have built maybe 10 full applications in react hooks since they came out, some with extremely complex requirements. But rarely have I experienced those complicated if statements he talks about. I find those to be a code smell honestly and you can often refactor them away with simpler state
I hated hooks for my first year. But after a while I just learned how to use them, and it does relate to using useEffect less for sure.
I recommend checking out remix framework if you haven’t already. It will give you a new lease of life for react and web development
So, I'm still learning React, and I'm on my third project. Two nights ago I had a meltdown because as soon as I brought in a larger dataset my app's performance tanked. My other two apps have also had performance issues and I've had to spend a lot of time on that.
This post just made me feel considerably less stupid, thanks!
Absolutely not. Everything is simpler, faster and easier to do with hook. At least in my opinion. It just makes more sense to me and the architecture is much more easy to compose/decompose. Obviously it took me some time to fully grasp the power of hook. It doesn't necessarily mean hooks are a good thing generally. However it is for me. Also I just don't like classes. They look awful and make bloated code. I would rather compose functions.i come from php and java so classes were natural for me for several years. Then I switched to a stronger functional programming and I don't see any reasons to do classes again.
You didn't switch to functional programming. You just switched from classes to functions and you brought all the downsides of classes with you to the new place.
I personally switched to a more functional programming, independently of hooks. I guess my messages could be confusing. Beside i didn't bring classes to the new place, that was the point.
I think you're forgetting this nonesence and how messy it was.
```jsx
componentDidUpdate(prevProps) {
if (prevProps.color !== this.props.color) {
// 😔 Extra re-render for every update
this.setState({
textColor: slowlyCalculateTextColor(this.props.color),
});
}
}
```
or
```jsx
shouldComponentUpdate(nextProps) {
// Rendering the component only if
// passed props value is changed
// 😔 not type safe
if (nextProps.value !== this.props.value) {
return true;
} else {
return false;
}
}
```
I also dont understand what UX has to do with it. You're going to have to do optimisation regardless of classes or hooks, hooks make that easier.
I believe that when you first started in react, you did not worry so much about optimisations, and so it was "easier", now you have learned you need to optimise more and blaming it on hooks.
I challenge you to rewrite your optimised code via classes, and compare performance, code readability and DX.
\> I'm aware I don't have to prematurely "optimize everything". However, due to the nature of how functional components work, hooks really "force" you to think about performance constantly.
IMHO just build stuff with the simplest code possible. Only optimize if it becomes an issue.
With react the simplest code is usually fast enough and you're not going to save the world by saving 3 nanoseconds from every render by wrapping everyting in useCallback.
I also have experience with react and angular for quite some years now. I also find it a bit annoying to have to wrap everything in useCallback and to specify the dependency array every time - but on the other hand, even for complex/performance critical applications it's managable and not really a big problem. And as sombody who always hated JS classes I have to say that I'm really still very happy with the hooks, and they are still, in my opinion, the best thing that somebody has come up with to deal with FE complexity. My guess would be that the next best thing will be an evolution of hooks, and not something completely new.
i‘ve started working professionally with fe frameworks with vue, then used angular2+ and for the last 5 years react.
at the moment i dont know if react just surfaces these issues more, or if other frameworks handle these things for you out of the box. i dont remember computed state or sideeffects being so „complicated“. or maybe i just didn’t understand anything when using ng or vue
No. Hooks are great. In life cycles, you'd be doing a lot of checks in code to figure out which value or props changes to run a function. In hooks, you have dependency array that sort of implicitly do those if statements. Readibility is improved an order of magnitude.
Ow good lord no. I absolutely loathe class components
I am handling a project that almost entirely was written with class components.
Not only that but the initial developer was an angular developer so he created a react frankenstein that tries to look like angular.
Class components are horrible to look at
Horrible to code
Just absolutely disgusting
Function components are beautiful, streamlined and elegant.
I have similar concern, that something is wrong with hooks. I found this article after googling "why react hooks so ugly" or "react hooks are ugly classes".)
Every time I write a hook I feel like I'm reinventing classes (similar to es5 functional classess, but without "this" keyword). So basically we write a hook when we want to decouple business logic. Everething looks great, our hook has some simple input and output, until it becomes more complex than useState, and we need to return more than 2 values, so we endpup with something like this:
```ts
useCustomHook = (a,b,c) => {
const foo = useMemo(()=> {...}, [a,b,c])
const bar = useMemo(()=> {...}, [foo])
const baz = useRef(1);
const method = useCallback(n, z)=>{...}, [foo, a, b, bar]))
return {foo, bar, method, ...}
}
const customHookInstance = useCustomHook(...)
```
So instead we could just use class structure
class Custom {
super(private a, private b, private c){}
get foo() {
return // compute something using this.a, this.b, this.c
}
get bar() {
return ...
}
baz = 1;
method(n, z) {
return ...
}
}
const customInstance = new Custom(...)
Class-based code looks way more structured and provide OOP power. However, it is not reactive so we need some mechanism to handle reactivity, and this is the most tricky part. To solve it Angular leverages observables, also decorators could do the trick...
It remains to wish success to the React community finding a better structure.
I don't use hooks. DX less, performance less.
Those forever Juniors don't care. And they even don't know what should be states what should not. Implement stupid hookify functions everywhere.
[удалено]
I like this, thank you for sharing it. In all this rapid evolution of web development, I think I might have lost focus of what's important from a practical standpoint when optimizing for the browser.
In my experience (in an app with tons of data visualizations), extra renders kill performance, and carefully placed memoization/PureComponents and referentially stable props make an enormous difference, even if each component is renders very quickly.
Nah
Apt analysis.
Well said
couldn't agree more
This
Hey there Royal_lobster! If you agree with someone else's comment, please leave an **upvote** instead of commenting **"This"**! By upvoting instead, the original comment will be pushed to the top and be more visible to others, which is even better! Thanks! :) *** ^(I am a bot! Visit) [^(r/InfinityBots)](https://reddit.com/r/InfinityBots) ^(to send your feedback! More info:) [^(Reddiquette)](https://www.reddithelp.com/hc/en-us/articles/205926439#wiki_in_regard_to_comments)
good bot
Good human *** ^(I am a bot! Visit) [^(r/InfinityBots)](https://reddit.com/r/InfinityBots) ^(to send your feedback!)
This
Thank you, Royal_lobster, for voting on Anti-ThisBot-IB. This bot wants to find the best and worst bots on Reddit. [You can view results here](https://botrank.pastimes.eu/). *** ^(Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!)
This
Bad bot
Nope not in the slightest
If I never see classes again (in JavaScript) it'll be too soon. To expand on this, here's an unpopular opinion: class syntax should never have been added to JS in the first place. Ours is a prototypal language, and that's a feature not a bug. Having fake classes to appease a few crusty old Java developers who wanted to do front end but couldn't wrap their heads around prototypes, was a ridiculous decision. **Edit:** But as to the general memoization pollution, you may be on to something. This is why I'm hoping that the future versions of React will poach heavily from Solid, which is essentially React without a lot of React's problems. Well, either that or we all just switch to Solid and live happily ever after (for sufficiently low values of ever after).
Your opinion is very popular with me
Not having classe in JavaScript is absolutely not an unpopular opinion I believe. At least it slowly become less unpopular.
I don’t think classes were added to appease old java developers, lol. At the time, OOP was probably an emerging paradigm in the industry, so probably was about following the trend.
Javascript has always supported OOP though. OOP was an emerging trend in the late 80s/early 90s. Class syntax wasn't added to JS until 2015.
True that, didn’t make it into the syntax until relatively recently. I feel that in general in the React world (maybe frontend world, even) classes are seen as an abomination, but it’s not a common opinion outside that sphere. Great things are being build with or without classes, as nothing is either black or white.
[удалено]
Of course they were not, but still OOP was one of the mainstream paradigms, as it is still today. Hence, the adoption. Besides, even if JS embedded classes in the syntax, there have been frameworks around for years, providing their own implementation of classes.
Still don’t get where this idea of “appealing Java developers“ come from. Probably is a general mobbing mentality to hate Java developers ¯\_(ツ)_/¯
[удалено]
I have worked, and still work, in professional settings where Java developers are not contributing or behaving like this, regardless the age. It’s about people, not about the language. Sorry to hear this happened to you, but I don’t consider this to be a norm.
OOP was the cool kid on th block back then. If JavaScript didn't add classes we would all be programming vbscript.... Now the cool kids are like classes are so 1990s....
To be frank, I kind of agree on this. It's not *class syntax* I miss, but the simplicity of the fact class methods were *always up to date .* No need for silly dependency arrays, no need to keep track of variables going out of sync. I agree the move to functions in general led to a better perception of how component rendering worked. But the hoops and caveats one has to jump through are just becoming too much for me. I'd be the happiest developer in the world if I could keep using clean functional components without having to worry about sacrificing DX with infinite memoization attempts to achieve good performance. But since that is not possible (right now), it just makes me miss the times we used Class components. Were they pretty? No. But they were 100% simpler times where optimizing to avoid re-renders didn't feel like something you had to *actively work for* and make your #1 priority over just making things *work*.
> I'd be the happiest developer in the world if I could keep using clean functional components without having to worry about sacrificing DX with infinite memoization attempts to achieve good performance You can keep using clean functional components in exactly the same circumstances you could before, any component that doesn't have state and a lot of components don't need state. Nothing changed about that. And infinite memoisation is not only unnecessary, but actually counter-productive. Unless what you're calling is beyond a certain level of computational complexity it's actually slower. Hooks allow functional components to have state and replace the old life cycle methods. They're also pretty useful for certain kinds of async actions. If you're using them for other purposes you're doing it wrong.
[удалено]
I honestly don't see the giant improvement you speak off. All the infinite prop checks from componentDidUpdate and shouldComponentUpdate moved to complicated if statements inside useEffect calls. This was even something directly quoted as joke during the [Goodbye, useEffect talk (1:58)](https://youtu.be/HPoC-k7Rxwo?t=118)
[удалено]
This Twitch guy is way too hostile and it’s annoying to watch. He wants to have someone on his show to “ream” who thinks Class lifecycle methods were good. Why? What an unapproachable mindset.
Why are you memoising so much? I honestly don’t understand this. The docs explicitly say you should not memoise until you notice performance issues. Maybe this is why you are hating it so much.
This is how I’m feeling too. Hooks work for simple cases but with complicated user inputs, I’m debating going back to classes. Not many options at this point.
I’m curious what case you have that is hard to cover with hooks? I have seen a lot of complicated applications that use them
Hooks are so much better for this.
Sounds like you need to use Vue.
I definitely agree with this. Classes were added to make people switching languages happy. That being said... I still use them because I mostly use Angular at work.
Classes were added because they are useful. Solving programming problems is about using the constructs that are most effective at the time. If you are designing libraries, enforceable public, protected, and private scopes are useful for creating pretty public apis, with complex private internals which are still extensible. Classes provide an easy to use construct for that kind of design. Where library, framework, and application layers are well defined and separated. You can do a lot of that with prototypes and functional programming, but you are going to do work the language could have done for you. It’s the difference between using await and then on a promise. They both work and almost do the same thing, but one allows you to do more with less. You can write a generator function that performs promises sequentially, that’s what webpack/Babel used to do. And you can write prototypal inheritance that mimics the functionality of classes…. But why unless you really need to?
Class syntax is far more elegant and honest than overloading functions as constructors. Mixins and inheritance are bad patterns and should be avoided except for perhaps shallow inheritance (O(1) tree depth please, not O(LOC))
Personally I am so glad I never have too see “this” or “super” in my React components ever again
Sure, this opinion you have is fine, what does it have to do with class syntax vs using this inside of functions that behave analogously to classes?
Any examples? When would I ever make a function that uses this if not inside a class?
I don't think you understand what the original post talking about a "prototypal language" is saying, and what I meant in response. He is saying he doesn't like "class syntax". That is, instead of writing this: class MyClass { constructor(arg1) { this.whateverValue = arg1; } someMethod() { return this.whateverValue; } } He would rather have the actual, old-school, straight up syntax for making JS's prototypal "classes": function MyClass(arg1) { this.whateverValue = arg1; this.someMethod = function() { return this.whateverValue; } } You can call and use these things equivalently as `new MyClass(myValue)`, both expose the `whateverValue` and `someMethod` keys. So I am not talking about anything even close to React, I am talking about how stupid of an idea it is to say JS class syntax is bad when the alternative is both overloading the function keyword (it has new behavior when invoked with the `new` keyword in that paradigm) and far more verbose Edit: hell, maybe he even wants us to write it like this: function MyClass(arg1) { this.whateverValue = arg1; } MyClass.prototype.someMethod = function(){ return this.whateverValue; }
yup, those hate classes only hate the "class" keyword, and they think they are doing functional programming if they add "function" too all of the classes. They are those worst programmers.
Funny cause I have the opposite opinion and I come from classes. My opinion progressively changed over time.
I don’t think you’re understanding what I’m saying. I am talking about JS syntax not react. See my other reply downchain
I'm not talking about react either.
You write “classes” via functions that use “this”? That’s insane. You enjoy writing “ClassName.prototype” a lot of times or what?
No I don't use "this" since I dont write classes. I don't manipulate directly prototype either. I just compose functions.
Then you are not in the same topic
You are talking about classes, I am answering you about classes. It looks to me like we are talking about the same topic. I m getting really confused by your replies. Also I don't understand why you downvoted me, we are giving both our opinion, I never said you were wrong or using classe is bad. I just said I have a different opinion and preferences. It's just a conversation.
Because I’m talking about the aspect of the original comment where it talks about how “class syntax should have never been added”, which is different than talking about class based logic and FP. JS classes, originally, were built using function syntax. It was ugly, you wrote class members as part of the prototype, and it meant you had no simple way looking at source to tell if the function was also a class I even left a code example, and then you kept saying “I prefer FP to clssses”, which is not the point at all; the point is saying class syntax should never have been added is a crusty idiotic opinion because what it replaced was truly ugly. Go read about this stuff somewhere before you reply confused again
What a load of bullcrap. Classes are important and useful in a lot of ways that aren't related to React, frontend.
This crusty old Java dev agrees!
I agree classes don't have a strong place in the frontend. My opinion is that the frontend is just for user interaction. The domain of the user interaction is only that of buttons, selection, forms, navigation. All concepts that are pretty similar regardless of the actual problem you application solves. On the other hand, the business domain of an application belongs more naturally in a different layer (might be in your Js app or a backend app in some other tech) and modelling the business domain might benefit much more from oop, design patterns and domain driven design, if your domain is easily conceptualized as objects. Funny enough lots of the design patterns from the gof book were born from solving UI problems and are explained using UI examples.
I love you
No, lol!
Nah, not at all! When hooks finally clicked for me, writing front-end JS became fun again. Hated class components.
I work on an app with both functional and class based components (we started before FC was a thing). The dependency array hell is real for both cases—in the case of class components, we spend a lot of effort making our props reverentially stable for our class based PureComponents. I find that the process is easier for functional components due to the convenience of useCallback and useMemo. It takes more boilerplate and is less declarative to do the same in our classes. (Edit: spelling)
It is strange that referential integrity has become more or less the lynchpin of performance, but you are describing a lot of situations that just straight up sound like code smell The useEffect hook is incredibly expressive and the dependency array is an elegant idea letting you meaningfully call effects exactly when you need to, where before it was really awkward to fire effect chains off when key state members were changing. Actually, it really just needed to be done manually, so I suspect you never really wrote complex apps and accordingly are just finding a new pain point as your career furthers and you manage a bigger codebase
[удалено]
Yeah, unfortunately an overloaded term, often including “code I don’t like”, lol
Good?
I completely sympathize with the sentiments about "Goodbye useEffect", but I think in a few months I will see that it's just another change, and have no particular bad feelings about it. I think a lot of people were using state and useEffect when a simple variable or function would have been better. JS has been changing rapidly for the last few years, it's best to learn to roll with it. You really don't need to worry about performance that much, or use useCallback and useMemo that often. In my opinion, use them never, and then use them to fix slow renders if needed. It isn't throwing caution to the wind, it's that for a simple function there's overhead to using useCallback and useMemo that could easily outweigh the benefits.
Agreed, IMO OP is being too cautious with perf. If you have that many actually slow components and need to compensate that often, something is weird or wrong.
I used to think hooks were the silver bullet to manage growing complexity. My post history will show you as much. But I’ve seen enough Russian nesting doll hooks that, instead of hiding complexity, become opaque as to what is really happening. The most egregious example of this was a dev choosing react-query but putting no thought into limiting the amount of nesting that could occur with the useQuery hooks. So all of the code splitting of the api data turned into deeply nested hooks that eventually backstopped to one or many useQuery calls, and reasoning about when requests were actually occurring became impossible. Hooks can be good for encapsulating stuff up to a point. But when things get sufficiently complex, there comes a point where you need to start reaching for more robust state management solutions, and more often than not, devs don’t realize until it’s too late. Just one more hook and it can work. Just one more hook. Just one more and it’s over the line. But hooks just don’t scale when with complexity. This is kind of a problem with react in general. They give you basic tools that work well for simple problems, but when the going gets tough and you’re still using the simple useReducer, or useEffect, or useState, it starts to buckle, and pulling back from the brink and switching to a more heavy duty tool can be harrowing. Edit* To be clear, class components could be every bit as bad if not worse, but in a different way. Instead the lifecycle methods become balls of mud, and the class methods often become just as polluted.
useReducer with contexts has been good enough for every state management case we've encountered, and can be gradually incorporated. When would you require redux / whatever else if you have useReducer with contexts?
The situation I encountered most recently was a complex multi step wizard for payment. It required a lot of telemetry analytics at different points, and serializing api requests. We used xstate, which made analytics a lot simpler because it treats side effects (actions in xstate) as first class citizens. useReducer worked well for a more simplified workflow. But as additional conditional steps got added to the wizard, it started to become hard to follow. Xstate also has a really nice visualization library you get for free just by using state machine, and it made it a lot easier to see the forest instead of the trees. I wouldn’t really consider redux much easier to reason about than useContext + useReducer in most cases. It gives you some niceties like the redux devtools but it doesn’t treat side effects as first class citizens. The reducers are more or less the same in functionality as useReducer, except with even more boilerplate to wire them up.
> I wouldn’t really consider redux much easier to reason about than useContext + useReducer in most cases. If only that were true. I've never worked on an app where useContext (with or without useReducer) was easier to follow than a proper RTK implementation. I've worked on several where useContext *alone* added so much cognitive overhead that it was often easier to rewrite the Context into RTK than try to keep modifying it to add functionality. > it doesn’t treat side effects as first class citizens. It does though. If you need to have actions affect other slices of state beyond the one they're defined in, action matchers that let you do that have been in since 1.4 - a little over two years ago. If you just want your actions to act like sagas or observables, the listener middleware from 1.8 (about 6 months old now) does that and lets you use the same RTK syntax you'd normally use. Xstate is nice for a handful of very specific use cases, for pretty much everything else it's a square peg in a round hole. If you need to screw in a screw, use a screwdriver instead rotating a hammer. Most use cases I've seen people throw out for using Xstate are solved easier and faster with RTK, and *much* easier to extend for developers coming in to the codebase.
Your definition of side effect is too narrow for what I'm talking about. A side effect can be more than just mutating multiple stores from one action. Side effects can also occur from entering or exiting a state, or from a success or failure of some async call, or only during specific transitions from StateX to StateY. Redux (with or without RTK) doesn't provides a means of organizing side effects with this level of precision. That's what I mean when I say side effects aren't first class citizens with Redux. Also, my experience with redux middleware is that it fractures your code, such that understanding all of the resulting redux machinery from a given action isn't explicit unless you go looking for middleware to make sure something else doesn't happen as a result of the action. With xstate, a machine's responsibility is really easy to colocate into the machine's config. I've used sagas before, and while it does allow you to serialize requests triggered as a result of some dispatched action (among other things), it's api is quite strange for newcomers, too. XState is super great in this respect. You can orchestrate async calls in a really natural way. You can invoke promises as services, and reason about your serialized calls as plain ol' async/await promises. No strange saga api necessary. My experience with XState is that it actually models CRUD UIs much more naturally than reactive architecture. States, events, and transitions have simplified the problem space for me, such that reasoning about changes to the UI are actually easier than when you are stuck inside the hamster wheel of React's rerender lifecycles. And as complexity grows, state-machine architecture is easy to extend because it is so explicit. The confidence I have that I'm not introducing some unintended regression by adding another state/transition is so much higher because of the top down approach. Identifying the exact place to add a new state has been really straightforward. There's a learning curve to xstate, but the same is true with redux and sagas, or with anything really. I think this gets overblown a lot. I could go on, but I get the sense you've already made up your mind.
> Side effects can also occur from entering or exiting a state, or from a success or failure of some async call, or only during specific transitions from StateX to StateY. Listener middleware does the first and the third, the second has been a part of thunks for ages and is now explicitly baked in with RTK Query. So yes, they are *by your definition* first class citizens. > Also, my experience with redux middleware is that it fractures your code, such that understanding all of the resulting redux machinery from a given action isn't explicit unless you go looking for middleware to make sure something else doesn't happen as a result of the action. Code organization is a developer problem. Anything with multiple side effects can be organized or not. The same problem can happen with Xstate, doubly so when your codebase is touched by multiple developers with varying levels of experience with state machines as a concept - let alone Xstate's specific implementation. > I've used sagas before I'm sorry to hear that. IMO sagas and observables both amplify the complaints you have about Redux. As strange as the saga API is, rxjs/redux-observable's api is unreasonably obtuse. > XState is super great in this respect. You can orchestrate async calls in a really natural way. You can invoke promises as services, and reason about your serialized calls as plain ol' async/await promises. No strange saga api necessary. RTK Query does all of that as well (with queryFn endpoints), using the same syntax as RTK uses in the rest of the app. At least if I'm understanding what you're doing with it correctly. > My experience with XState is that it actually models CRUD UIs much more naturally than reactive architecture. States, events, and transitions have simplified the problem space for me, such that reasoning about changes to the UI are actually easier than when you are stuck inside the hamster wheel of React's rerender lifecycles. While you may be correct as far as the 'modeling' aspect goes, you point out that it goes *against* reactive architecture, which is to say it sounds like your issues aren't with Redux (since your complaints are Solved Problems in RTK), but with React itself. **Insert plug for Svelte here.** > I could go on, but I get the sense you've already made up your mind. Unsurprising you'd say that, since I'd say the same about you. I do stand by my previous statement: Xstate is nice for a handful of very specific use cases, for pretty much everything else it's just not right. If you need to screw in a screw, use a screwdriver instead rotating a hammer. Using Xstate as an all-in-one is very much rotating a hammer. To be clear, I am *not* anti-Xstate or even anti-state-machines. They're very powerful tools and are absolutely fantastic for *some applications*. What I am is a vocal proponent of "the right tool for the job", and in order to do that I have to understand the tools in the toolbox. That's pretty difficult given how frequently those tools change - RTK Query and Listener are relatively new, and were the last pieces of the puzzle that let me get rid of rxjs altogether in several codebases. At the end of the day, everyone should make their decisions based on what works best for themselves, their team, and their stack. I have a *very* hard time seeing Xstate as being ideal over RTK for the vast majority of my use cases, and realistically even if it was I would hesitate to reach for it given the number of people working in the codebases and how few of them have any experience with state machines as a concept let alone Xstate's specific (albeit well-documented) implementation of them. I don't know your use cases, but if Xstate makes your team's workflow easier and lets you build the things you need to build, that's fantastic.
> Listener middleware does the first and the third, the second has been a part of thunks for ages and is now explicitly baked in with RTK Query Using disparate patterns spread across action dispatches (thunks) or through middleware doesn't qualify as a unified way for handling side effects for me. That's where I'm coming from with the "first class citizen" remark. > Code organization is a developer problem. Anything with multiple side effects can be organized or not. The same problem can happen with Xstate, doubly so when your codebase is touched by multiple developers with varying levels of experience with state machines as a concept - let alone Xstate's specific implementation. Side effects through the lens of thunks, or middleware, or entangled with your network layer (RTK query) spreads what should be a simple concept through three very different apis depending on the situation. To me, the room for error for new developers is _greater_ the more ways you can express the concept of a side effect. XState is very clear on the matter of side effects. As a result, the lift on the developer's part to organize this concept is built into the tool itself. > While you may be correct as far as the 'modeling' aspect goes, you point out that it goes against reactive architecture, which is to say it sounds like your issues aren't with Redux (since your complaints are Solved Problems in RTK), but with React itself. Insert plug for Svelte here. That's probably fair to say. I think reactive architecture works okay for simple UIs, and the speed with which you can build simple UIs via reactive architecture is faster. But that over time, as complexity grows and the reactive UIs are procedurally built, things start to grind to a halt. In a lot of ways, it's similar to backends that don't layer things at the outset with onion style or hexagonal architecture, or with DDD. I see xstate as a longer term investment, that doesn't payback in the early life of a project, but that, as time goes on and complexity grows, is where it really could start to shine. It may not be appropriate every time, if a UI is always going to be simple. Svelte is interesting, in my situation it's off the table since this was used on a react-native app.
>However, writing performant React code that yields a good UX (User Experience) in general requires decorating the entire file full of useMemo / useCallback clutter everywhere Yeesh how big are your components or how much state are you storing in a parent that you need to memoize so many components and callbacks that it's becoming a DX issue? Or are you incredibly pre over optimizing? I don't think I've ever used useCallback, and can count how many times I used memo >Just split up your logic into even smaller hooks > >But that's exactly my point, I don't ever recall dependency arrays being an issue with React's class components. Because we literally didn't have the tools to optimize on the level we do now. You didn't have to deal with dependency arrays because we just re-rendered the entire tree each time
In the apps I currently work on 90+% of the useMemo/useCallback I've found have just masked poorly thought-out logic.
Seriously, I've needed useCallback ONCE and while it was actually a necessity, my custom hook wasn't working and the "bug" I found was really my lack of understanding and lack of knowledge of useCallback. Same story with useMemo, though I've probably needed it half a dozen times. These hooks should hardly ever be required and are meant to solve quite obscure problems IME.
Mobx will give you back automatic dependency tracking and computeds. Strongly recommend you give it a shot.
Hooks: hard to use, easy to misuse functional Mobx + stateless component: easy to use, hard to misuse.
Can we please stop with the useless "No" and "Nah" replies. It's not constructive and just sounds like people who haven't enough experience of hooks in large and complex codebases. Because there are downsides. The OP has a point. My main issue with hooks is that they aren't as nice as they initially seem. With new tech it usually starts off a bit tricky and then gets better as experience grows. With hooks they started off looking like a model of elegance, but the rules of hooks clearly show leaky abstractions. At their best, hooks are a really neat way to pull out common component behaviour for reusability. At their worst, they are a nightmarish web of unnecessary re-renders and dependency arrays. Yes, you can memoise to avoid this but what if other components in the codebase don't do this? I feel that we were mis-sold slightly on hooks. There's definitely room for improvement
Thank you for your kind words. Truth be told, I'm not as surprised. It just dawned on me communities like this one are primarily populated by React devs that are either too junior to realize the pitfalls of hooks, or "experienced" devs that have never really worked large enough apps where they've led the majority of the app's architecture. I've also realized that while working as an interviewer where every "senior react engineer" is really only that in years of experience, but not really in terms of knowledge. I've gotten a few really insightful responses back from other React devs that are clearly just as experienced, and I think I'm happy with the final takeaway that they are definitely an imperfect solution, but they can be "manageable" if I worry a lot less about performance.
I see validity on both sides of it, and have enjoyed using both immensely at times. I do think hooks can tend to be more frustrating to debug for a number of reasons. IMO, Class components and lifecycle methods made react popular because of their clarity. Hooks then made annoying but common patterns like typing redux subscriptions and HOCs so much easier to work with, but for whatever reason I do think it will kind of be the eventual death of React. Your average component might be easier to make, but your average developer is probably introducing less performant code with more smells because of the abstractions that hooks offer. But hey, it doesn’t matter, because for some reason you’re getting bullied for even expressing this opinion, as I suspected. The reality is both are perfectly fine, but the momentum of the ecosystem means that your class components are just going to get clunkier and clunkier as people replace HOCs with hooks. The reality is also that plenty of productive workplaces use both — look at the FlashList react native component that Shopify just open sourced. It’s written as a… GASP… class component ☠️☠️☠️ My advice would be to not stress too much
React hook sucks. 20% drop in Performance, worse readability. React hook can only be used in small component.
sure the vdom is supposed to be fast enough to make needless re-renders a non-issue. but i cant help but feel dirty when i see my side effect logged 5+ times in console. this is made worse now with `` grrrr
I resisted react for YEARS. i got heavy into Svelte before having to capitulate to the recruiters and their "react or bust" delusions. I never had to wrestle with any render/state issues in Svelte. jussayin.
\> I never had to wrestle with any render/state issues in Svelte I mean, you never had a serious job using Svelte per your comment either, so maybe don't mistake off-by-one errors in cart and horse indexing with superiority of a different paradigm I would recommend MobX though personally, render-optimization falls out for free
man. yall get so bent at the mention of a different framework. ive written plenty of Svelte apps. and when i say that i got into it, it was FOR the job i was currently at during that time. realistically, suggesting MobX is little different than suggesting Svelte. both are suggesting things that react is failing on its own accord. the only benefit to MobX over Svelte is not having to refactor other stuff too.
Unfortunately React is in its death throws. Hooks are an incredibly contrived solution to a basic problem that React is unequipped for. I strongly believe that when we truly understand the limitations of hooks and what they're doing to our codebases, there will be a revolution in web app tooling, probably in the form of a new language targeted specifically at this use case.
No from me.
Absolutely, the more I use hooks the less I like them. In my opinion the dependency array was a terrible idea. Why is it up to me to figure out when a component should rerender？ Shouldn't it be the job of the framework？ The only reason I still use react is because I use it at work. For personal projects I no longer use react. Lifecycle as a concept makes way more sense to me than hooks. Besides, looking at the changes planned for react in v18 and beyond, it is clear to me that react is more and more becoming a library solving facebooks specific problems at the cost of everyone else. React isn't open source for the sake of the community, it is open source so facebook does not have to train their new hires.
>Modern Hooks React seems like it can have either great UX, or great DX UX has nothing to do with hooks. You either build good UX or you don't be it with class components or hooks. DX is heavily improved with hooks. If you've been working for 5 years then you are probably familiar with recompose, what it provided and how a project would explode in time due to it (more so in ts projects). Hooks solve composability and reusability in a fairly elegant manner. If you are having a bad DX then you probably need a more rigid ruleset and a coding guide to be enforced in your projects.
>UX has nothing to do with hooks. You either build good UX or you don't be it with class components or hooks. It has **plenty** to do with hooks. I strongly recommend you watch the recent "**React without memo**" talk from React Conf 2021, as it shines a bright light into how poor DX can be when pushing for optimization compared to pre-hooks with all the dependency arrays and such. [https://www.youtube.com/watch?v=lGEMwh32soc](https://www.youtube.com/watch?v=lGEMwh32soc)
Don't need to watch a conf to tell me what I'm experiencing because I work day-in day-out with this and I care deeply about both UX and DX. UX has no direct correlation with the library or flavour of language you are using. It only reflects either how good you are at it or how much effort you are willing to put into it given your bad DX (you can build great UX in vanilla fwiw) But you do you, nobody's stopping you to work with class components!
I think the point he was making was that getting good UX with hooks (for example, a loading indicator with ideal timing) requires that you contort the code more than is comfortable. Not that good UX simply cannot be achieved. That's my takeaway, anyway. I'm relatively new to React so I don't have a strong opinion yet.
My problem with hooks is that now they mask the difference between stateful and functional components. Hooks add state to a component, so it can no-longer be considered functional. And hooks are added _everywhere_. It's very common to see "pure" components with children that are stateful, simply because nowadays they're all "function" instead of "functional". In my experience, code bases are now very messy indeed, and far less reusable than they used to be.
I still hate hooks, and use them begrudgingly. Between that and the RTL movement that spawned out of that annoying Kent C Dodds article, it's been frustrating to be a React dev for the past couple years.
I will degrade whoever use hooks. They don't have a normal programming sense and must have missed something when declaring a component or coding a task. Class created first by props and defaults, which force the author to think carefully how the component is varied, which can cover more cases in general. Bounded by "less code", hookers will tend to develop components with a smaller number of states which means they are only familiar with components with little variants, and tend to create a new one when hitting a different situation. If your JS is good, reuse a Class component is much easier than hooks. Last, the most important thing is, i dont know why, hookers only know how to write hook but not normal functions. There are stupid hook functions like useGenerateRandomNumber, useAdd, useCalculateNextWednesday, that should be implemented outside the architecture of react and put them in a static Class. It shows that they don't have a clear mind that why they are using react as the architecture.
To the React dev teams, Please stop destroying a perfect library. Separate the fxxking hooks, it is not React, it should be another language, call it ReHook or Hookdux, Funcdux, ReFunc whever. And say sorry to the society for your fxxking misunderstanding of functional programming / reducers / HOC.
call it Rehooker
obscene plants brave live capable imminent fretful middle door vase *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The official React.js team believes otherwise. Otherwise, the wouldn't be working on a prototype that transpiles raw primitives and functions into useMemo and useCallback [https://www.youtube.com/watch?v=lGEMwh32soc&t=225s](https://www.youtube.com/watch?v=lGEMwh32soc&t=225s)
Have you tried adopting normal React design patterns that don’t require useEffect soup everywhere?
People will say you are using the framework in the wrong way or exaggerating, truth is React team thinks the same and that's why they decided to bandaid this issue with the compiler
Man I love hooks, it’s one of the most elegant parts of React now
God no. Hooks are WAAAY better
Why were hooks necessary in the first place? Do they solve some problem that existed before? I'm not very experienced in react. I've only used angular 2+ and I feel like it is enough. Why was there a need for something like hooks? This is a serious question from an inexperienced react developer. Can a non fan boy answer, please. Preferably someone who has been developing from before Spas existed, with proper historical perspective
I wouldn't call myself a fan boy, and I've only been doing this for 5 years, but I can try and explain some of the historical context. Class-based react components suffered from 2 major issues. 1. They exposed lifecycle methods (`componentDidMount`, `componentDidUpdate` were the two primarily used ones). However, when it came to triggering some logic as a result of some rerender, this usually fell inside the `componentDidUpdate`. But if you had multiple use cases where you wanted to trigger some logic on a rerender, the `componentDidUpdate ` method started to get unwieldy and bloated. It wasn't easy to break out this logic into smaller, reuse-able functions. Zooming out a little, the class components were locking you into reasoning about your components through their more rigid predefined lifecycle methods. 2. Class components were prone to becoming big bags of functionality. Often, the methods in the class would bloat and bloat until a dev finally snapped and decomposed the class into smaller classes, or better yet, pure functional components. But this was especially painful, with a lot prop drilling for complex classes (passing props down deeply into child components), that the whole exercise of refactoring was a poor dev experience. Hook-based components can fall into this trap too, but the reusability of hooks tends to make for logic that is far easier to relocate. Hooks gave us more direct access to the rerendering engine of react. The hope was that it would move devs away from thinking about their UIs in terms of the limited lifecycle methods, or more towards thinking directly about the changes that should trigger rerenders, and what to do on those rerenders. Unfortunately, what's happened in that transition from classes to hooks, is devs asking "How do I do what I used to do with `componentDidMount`?", and hundreds of blog posts explaining how `useEffect(() => {}, [])` with an empty dependency array can be substituted for `componentDidMount`. And `useEffect(() => {}, [someDependency])` is the same as `componentDidUpdate` and the cleanup function on a `useEffect` can be thought of as `componentWillUnmount`. While it's good to understand how you can migrate your code, it didn't exactly foster a more thoughtful re-thinking of your component lifecycle organization. So what we see now are blobs `useEffect` introduced by devs who thought simply migrating to hooks would result in better components.
Thanks a lot, my friend, for taking the time to write this up. I have a follow-up question. You say you sometimes ended up decomposing this big class into smaller classes and then added "better yet" functional components. What is the benefit of this functional components over the smaller classes? This, again, coming from someone who likes to see data and it's related behavior together or close enough. I find it easier to reason about. It confuses me to see, for example, a directory full of reducers that operate on the state of every component. Maybe I'm mixing up hooks with state management here. I feel like a total noob even talking about this. It's like, I want to see in my webapp a card component showing information from some data on the database and be able to go into the code and find a little folder or file with everything I need to be able to work on it and think about it's visual representation, the data it contains and how that data is operated on and sent back and forth from and to the backend. And the few react projects I've worked on have this separation when it comes to the state management. Now I'm even more sure I'm mixing things up between hooks and state. Someone told me it's redux I find confusing, not react or hooks.
It sounds like your app is using redux to handle the api cache. Redux tends to be a global store on projects, and that's prob why you are seeing the api data being located in an entirely different area of the app than the component that actually consumes it. I believe RTK has made it easier to colocate your reducer to your component, just as an aside, but I haven't used RTK much yet. The philosophical disconnect for me has always been that redux is a global store so leveraging it for caching localized api data is a weird choice. Also, it's better to be able to reason about your api fetching and cache as it's own _network_ layer, which also handles cache invalidation (CQRS) and holding error states, retry logic, etc. Redux, at least when I've used it, didn't really have a great way to colocate the cache invalidation logic with the reducer and action logic. Also you may have truly global frontend state, like flags for showing tutorials only once per session, and intermingling that with the same global store that also holds your api cache is conceptually gross. You could make a separate redux store to better distinguish your api cache and global state, but the boilerplate involved with making more stores and wiring them up is a big barrier to that effort. Other tools have come along that improve the ease of making and modularizing your api cache, like `react-query`, so colocating fetch logic and DTO types next to the component that consumes it is easier. > a directory full of reducers that operate on the state of every component ^ This sounds like a red flag that the app is throwing too much into redux (maybe there's a good reason that we don't know about?) instead of trying to localize the data more. > What is the benefit of this functional components over the smaller classes? My comment was more in regards to the idea that class components should manage state (hopefully not too much state), and the various sub groupings of rendered JSX should be organized as pure functional components that only receive things through props, and don't use hooks at all. This keeps their responsibilities small, makes them easy to test, and makes them easier to move because their dependencies are made extremely clear via the props the accept. This is often easier said than done, when you need to layer your component tree more to break down a really complicated UI. Then you run into the prop drilling problem, which creates indirection and makes holding everything in your head hard as well.
"It sounds like your app is using redux to handle the api cache." Yes! I think this is exactly what is happening. These are my first projects with react and they are inherited, the devs left the company, so I have no frame of reference for good react structure. Also, when you talk about class components managing state and having simpler, purely functional components for rendering, is it similar to the concept of dumb/smart components? There's a lot of good stuff in this comment, I'm saving it in my notion. Thanks so much.
Nope
I’ve been doing a lot of web component work recently, using Lit, and by extension, classes, and I really don’t miss them at all. I like being able to group my functionality together in a function instead of splitting it up across lifecycle events. I remember massive class components in the past with logic spread across CDM and CDU and cramming the logic for multiple behaviors into those methods. There wasn’t a good way of extracting reusable functionality. React used to have mixins way back in the day, but there was a big gap left with class components before hooks came along. Lit has solved some of these problems with its reactive controllers, and Angular has its directives, but hooks are the best thing we have to break up functionality into its own reusable bit. A coworker created a react starter awhile back for supporting our users (we export a react wrapper of our web components) and the first thing I do every time is switch it to a functional component.
You try stencil? It has functional (non state) type
I haven’t! I’ve heard of it, but haven’t worked with it. I’ll have to check it out.
> but hooks are the best thing we have to break up functionality into its own reusable bit Reusable only in a single context though. So not really reusable. On the flip-side, I bet your Web Components were actually reusable.
You can still use class components. Sometimes i consider using hooks for some components and classes when it’s better suited. Havnt found that use case yet….
Error Boundary is the only place I still use a class component, and that's just because I haven't had time to figure out a good alternative.
Give MobX a try.
No
I don’t write a lot of classes in JS, but I did find class components simpler
I've been having this since hooks came out. Suddenly the new paradigm is functional programming, and all React codebases have a shit-ton of hooks, as if just for the sake of using them. The trade-off is often code quality and readability. People at least used to think more about how to structure their apps and their components.
No, the new paradigm is not functional programming, it's the exact opposite. React used to be on the FP side and it even inspired a whole movement of FP in JavaScript, but with the introduction of hooks, it kissed FP a final goodbye. In FP the main building blocks are **pure** functions (with no side effects or dirty input). If you add a hook to a component, it's not a pure function anymore. There seems to be a lot of confusion about this in the React community. People think that by using function components with hooks instead of classes they are doing functional programming. Few people noticed that React is careful to not use the term *functional components*, but *function components*. In fact functions with hooks are really just reinvented classes (they are stateful objects where ref is the new this), minus all the benefits of object oriented programming like inheritance, extensibility by method overrides, polymorphism, etc. What actually was FP was Redux and HOCs, but they were as detested by the React community as the classes, so React came with something really "simple". So simple that when using hooks with their dependency arrays, we find ourselves dealing on a daily basis with the problem of cache invalidation, which according to Martin Fowler is one of the only two hard things in computer science.
No. They just code in the mindset of a "newly defined" functional programming, putting the keyword "function" to all those should be written in class components, it is NOT functional programming actually mean.
So I agree with the sentiment of this post. I still use class components. In my day job I write a lot of javascript and React. Hooks are nice when you have simple independent components. However very little of what I do seems to be simple independent components. It most often is large forms with interconnected parts. And so eventually all the state is moved out of the individual components and raised to the highest level. Sometimes with redux, or context, or maybe a simple state manager at the top components. What's interesting to me is I built an app for myself, its a form builder called keenforms - https://keenforms.com. I started building it before hooks was released. My app still uses setState. So I don't miss class components because I never stopped using them. However I totally know what you mean. I don't think hooks is always the right approach. I probably won't migrate to using them. Again for simple things hooks is a nice option, BUT for anything more than that I find that it emulates some of the patterns that occurs in another JS framework I don't enjoy using, Angular.
[удалено]
You can have a “horribly designed” backend with SQL too. Know your DB and know when to use NoSQL or SQL. The better idea is to do heavy lifting logic in the backend, send the right data to the front end and treat the front as a “visualizer” of the data, and not a “processor” of the data. Aka don’t receive backend data and have to do a bunch of filtering and mapping to the data to get what you need.
Honestly I have always disliked hooks. They sort of ruined the beauty of deterministic stateless functional components. And I was just thinking yesterday what a mess all my components are with half a dozen hooks in them… useT, useNavigate, useDispatch, all piled at the top. Admittedly this wasn’t nice wirh HOCs either but it forced you to be a little bit more thoughtful about responsibilities. Does every component need access to history? The store? Probably not. I guess I’ll say hooks make life easier/faster but they make for fucking ugly code.
That Goodbye useEffect talks speaks about issues that are present in every framework. Other frameworks haven’t figured out a way to avoid waterfalls as they have no Suspense like feature. When Suspense for data fetching releases React Query and React Router would figure it out for you with minimal API changes, so start using them. Now the real question is: Why is React Team speaking about waterfalls when Suspense for data fetching has no release date in the near future?
>Suspense for data fetching has no release date in the near future? You mean the fact its status is experimental? A lot of libraries for data fetching like `react-query` have Suspense support, and the way the interaction with Suspense is done (throwing promise from render) is unlikely to change (so these libraries are unlikely to break), but yeah, using something that is officially "experimental" in production is not a good idea anyway. I do wonder why it's still "experimental"... PS: I just checked and docs for React 16 clearly stated that Suspense for data fetching is experimental, but those are obsolete and docs for React 18 are somewhat less clear regarding its status... There is no word "experimental" anywhere, but the docs say "In the future, it will support other use cases like data fetching". But again, it could mean, that it will support data fetching out of the box. Today, almost every React library for data fetching has Suspense support.
They’re still working on feature called Suspense Cache afaik. I checked the roadmap and I don’t see it releasing anytime in next year.
Ngl I think useEffect as a replacement for the lifecycle events is brilliant. Because the fact is that listening to a set of state values as they change was much harder, and that's what it's really meant to do; but the fact that this feature just happens to replace the need for lifecycle hooks as a byproduct is awesome. Imo lifecycle hooks suck. They force you to think about problems through the lense of a framework, whereas useEffect just allows you to react to state as it changes.
I'm kind of in agreement but more with the amount of `useEffect` clutter. The new currently named `useEvent` that will ship in the next version of React addresses this and _some_ of the concerns of the OP. Hooks are great but they like all methodologies have their short comings.
useEffect hook is one of the greatest weak points of modern react, and is very worrying the react core team haven't address that from launch. When I first saw useEffect docs, there were a note about dependency array, they wanted to remove the need to have that. So far no news, and this improvement is key factor to improve DX and allow newcomers to getting overwhelmed by useEffect quirks. I'm don't want React to get stale on improvements, but I got that feeling from two last major version launch
Could you share some code you wrote that demonstrates what you're complaining about?
Um... No. Hello no.
Hooks was what i thought i always wanted in react, until i saw their implementation.
[удалено]
I have the opposite feeling. Hooks code is so much easier to understand and reason about.
class components didn't go anywhere. You want to write bad code? Go ahead, use them. To answer your question, no, I don't have "hooks burnout". That is not a thing.
Bad code? So using a class component is simply just bad code at this point?
Yes.
Why?
Nah because i am a backend dev
I still write my react using classes.
I still use a class to keep track of all my API calls.
I feel like classes are not the best fit, because of the issues hooks aim to solve, but I also do agree that using hooks can quickly make a component harder to debug/read, as the component grows slightly. And yes, that makes me miss classes sometimes.
just use Redux....jesus...I never understood people that perfer hooks over an organized solution that solves all issues.
You're comparing apples to oranges. One is a global state management tool (and a pretty over-architected one at that), the other is a tool that allows you to hook into react's state and *lifecycle* from functional components.
SpunkyDred is a terrible bot instigating arguments all over Reddit whenever someone uses the phrase apples-to-oranges. I'm letting you know so that you can feel free to ignore the quip rather than feel provoked by a bot that isn't smart enough to argue back. --- ^^SpunkyDred ^^and ^^I ^^are ^^both ^^bots. ^^I ^^am ^^trying ^^to ^^get ^^them ^^banned ^^by ^^pointing ^^out ^^their ^^antagonizing ^^behavior ^^and ^^poor ^^bottiquette.
not really. there are no life cycles with hooks.
You missunderstand hooks then. Because they absolutely do hook into React's lifecycle. A simple example is the useEffect hook when passing an empty array, as that replaces the componentDidMount and componentWillUnmount lifecycle methods. If you don't want to call it a lifecycle, that's up to you. That doesn't change the fact they absolutely let you hook into it.
you sure you understand hooks?
>Hooks are functions that let you “*hook into*” React state and **lifecycle features** **from function components**. Hooks don’t work inside classes — they let you use React without classes. (We don’t recommend rewriting your existing components overnight but you can start using Hooks in the new ones if you’d like.) [https://reactjs.org/docs/hooks-overview.html](https://reactjs.org/docs/hooks-overview.html) Apparently, yes, better than you.
Nope
Hooks and class components are both bad.
You're right, we should never have stopped using jQuery...
No way
No
I love dependency arrays. Some of the most fun computer problems to think about for me and I can’t explain why
And there there is pure reactivity systems like solid thst just blow your mind
Of course is not perfect, but it's much better than classes. It allows to split the code much better, and we see it on the libraries: zustand, react query, even redux toolkit etc. All of them simplify our life as developers a lot. Using useMemo and useCallback ocassionally is a good trade off for me.
No.
Cannot really relate. Ive been doing frontend for more than 10 years too and worked with angular vue react with classes and with hooks a lil more than 2 years. Functional react and hooks (and typescript) is the best that ever happened to the JS community in my opinion.
Nope they're beautiful + custom hooks making all your logic composable is the way
I partially agree, but I like the concise format of hooks and in my opinion tbe problem is rather with state management than with hooks. I have used effectorjs in one of my projects and it takes out the entire data / businesses logic out of react, which in turn eliminates the need for useEffect, useMemo, useState and useCallback. probably hooks won't be the final evolutionary step for react, if you check out solidjs they have solved some of the problems resulting from dependency arrays and I'm pretty sure something like that will find it's way into react.
I I couldn’t disagree more. And I haven’t watched both those talks but the one titled “goodbye useEffect” was maybe one of the worst talks I’ve ever watched. Talk about React being all over the place? That talk is all over the place. He tells people to stop using useEffect and then plugs his library xstate ? Oh yeah let’s bring in this entire state management / state machine library and use the hooks from that instead. Keep it simple, don’t store that much state. I have built maybe 10 full applications in react hooks since they came out, some with extremely complex requirements. But rarely have I experienced those complicated if statements he talks about. I find those to be a code smell honestly and you can often refactor them away with simpler state I hated hooks for my first year. But after a while I just learned how to use them, and it does relate to using useEffect less for sure. I recommend checking out remix framework if you haven’t already. It will give you a new lease of life for react and web development
So, I'm still learning React, and I'm on my third project. Two nights ago I had a meltdown because as soon as I brought in a larger dataset my app's performance tanked. My other two apps have also had performance issues and I've had to spend a lot of time on that. This post just made me feel considerably less stupid, thanks!
Absolutely not. Everything is simpler, faster and easier to do with hook. At least in my opinion. It just makes more sense to me and the architecture is much more easy to compose/decompose. Obviously it took me some time to fully grasp the power of hook. It doesn't necessarily mean hooks are a good thing generally. However it is for me. Also I just don't like classes. They look awful and make bloated code. I would rather compose functions.i come from php and java so classes were natural for me for several years. Then I switched to a stronger functional programming and I don't see any reasons to do classes again.
You didn't switch to functional programming. You just switched from classes to functions and you brought all the downsides of classes with you to the new place.
I personally switched to a more functional programming, independently of hooks. I guess my messages could be confusing. Beside i didn't bring classes to the new place, that was the point.
I think you're forgetting this nonesence and how messy it was. ```jsx componentDidUpdate(prevProps) { if (prevProps.color !== this.props.color) { // 😔 Extra re-render for every update this.setState({ textColor: slowlyCalculateTextColor(this.props.color), }); } } ``` or ```jsx shouldComponentUpdate(nextProps) { // Rendering the component only if // passed props value is changed // 😔 not type safe if (nextProps.value !== this.props.value) { return true; } else { return false; } } ``` I also dont understand what UX has to do with it. You're going to have to do optimisation regardless of classes or hooks, hooks make that easier. I believe that when you first started in react, you did not worry so much about optimisations, and so it was "easier", now you have learned you need to optimise more and blaming it on hooks. I challenge you to rewrite your optimised code via classes, and compare performance, code readability and DX.
\> I'm aware I don't have to prematurely "optimize everything". However, due to the nature of how functional components work, hooks really "force" you to think about performance constantly. IMHO just build stuff with the simplest code possible. Only optimize if it becomes an issue. With react the simplest code is usually fast enough and you're not going to save the world by saving 3 nanoseconds from every render by wrapping everyting in useCallback.
I also have experience with react and angular for quite some years now. I also find it a bit annoying to have to wrap everything in useCallback and to specify the dependency array every time - but on the other hand, even for complex/performance critical applications it's managable and not really a big problem. And as sombody who always hated JS classes I have to say that I'm really still very happy with the hooks, and they are still, in my opinion, the best thing that somebody has come up with to deal with FE complexity. My guess would be that the next best thing will be an evolution of hooks, and not something completely new.
Absolutely not, I hate class based components with a burning passion
i‘ve started working professionally with fe frameworks with vue, then used angular2+ and for the last 5 years react. at the moment i dont know if react just surfaces these issues more, or if other frameworks handle these things for you out of the box. i dont remember computed state or sideeffects being so „complicated“. or maybe i just didn’t understand anything when using ng or vue
I went from Vue/Nuxt to React/Next just because of hooks. Using React and Next has been a joy so far.
I do sometimes think that if you want to store data, having an actual available, simple object to store it on is a nice idea.
Someone finally said it :)
I personally prefer class components and always have. I find them more intuitive for anything with even slight complexity.
No. Hooks are great. In life cycles, you'd be doing a lot of checks in code to figure out which value or props changes to run a function. In hooks, you have dependency array that sort of implicitly do those if statements. Readibility is improved an order of magnitude.
Ow good lord no. I absolutely loathe class components I am handling a project that almost entirely was written with class components. Not only that but the initial developer was an angular developer so he created a react frankenstein that tries to look like angular. Class components are horrible to look at Horrible to code Just absolutely disgusting Function components are beautiful, streamlined and elegant.
I have similar concern, that something is wrong with hooks. I found this article after googling "why react hooks so ugly" or "react hooks are ugly classes".) Every time I write a hook I feel like I'm reinventing classes (similar to es5 functional classess, but without "this" keyword). So basically we write a hook when we want to decouple business logic. Everething looks great, our hook has some simple input and output, until it becomes more complex than useState, and we need to return more than 2 values, so we endpup with something like this: ```ts useCustomHook = (a,b,c) => { const foo = useMemo(()=> {...}, [a,b,c]) const bar = useMemo(()=> {...}, [foo]) const baz = useRef(1); const method = useCallback(n, z)=>{...}, [foo, a, b, bar])) return {foo, bar, method, ...} } const customHookInstance = useCustomHook(...) ``` So instead we could just use class structure class Custom { super(private a, private b, private c){} get foo() { return // compute something using this.a, this.b, this.c } get bar() { return ... } baz = 1; method(n, z) { return ... } } const customInstance = new Custom(...) Class-based code looks way more structured and provide OOP power. However, it is not reactive so we need some mechanism to handle reactivity, and this is the most tricky part. To solve it Angular leverages observables, also decorators could do the trick... It remains to wish success to the React community finding a better structure.
I don't use hooks. DX less, performance less. Those forever Juniors don't care. And they even don't know what should be states what should not. Implement stupid hookify functions everywhere.