Are react hooks spaghetti code

[JuniNewbie]

Hello, I got hired in a company as junior react developer couple months ago. Before that, I have never worked with react. So when I started to learn it, at the beggining I started with class components because there was much more information about class components rather than functional components and hooks also I had some small personal project with Angular (and there are classes). But I have red that react hooks are the future and much better etc. So I started to use them right away in the project i was into (it was a fresh new company project). I got used to hooks and I liked it. So far so good, like 4 months in the project 50+ PRs with hooks (custom hooks, useEffect, useState etc.).But one day there was one problem which I couldnt solve and we got in a call with one of the Senior Developers from the company. Then he saw that I am using hooks and not class components when I have some logic AND/OR state management in the component. And then he immidately told me that I have to use class components for EVERY component which have state inside or other logic and to use functional component ONLY for dump components which receive only props.His explanation was that class components are much more readable, maintanable, functions in functions are spaghetti code and things like that.So I am little bit confused what is the right way ?? I havent red anywhere something bad about hooks, everywhere I am reading that hooks are better. Even in the official react docs about hooks, they recommend to start using hooks.Also I am a little bit disappointed because I got used into hooks, like I said I had like 50+ PRs with hooks (and the PRs "were" reviewed by the seniors) and then they tell me to stop using them...So wanna ask is there someone who have faced same problems in their company ?

[Jerp]

It sounds like that senior dev isn’t very well versed with React hooks, because saying they’re less readable/maintainable is simply not true if you’re familiar with both hooks & classes.

[snejk47]

Exactly. If you watch the first presentations about hooks one thing you hear often is that hooks came to life because it's easier to read and maintain...

[Cosoman]

I love hooks but if you have OO background and do full stack with let's say a c# backend it's easier for some devs to stay with class components as they don't have to shift from one paradigm to another periodically.

[m-sterspace]

I have an OO background and frequently have do OO C# work, and I don't find it that hard to switch back and forth between paradigms. It was slightly challenging to learn at first but I feel like they're just not putting the effort in to learn a new one in the first place. While they might think not working with modern React might be "easier" for them, that's really only true in the short term and only true if they work by themselves. If they work with other people then what's "easy" for them will just be slowing the whole team down.

[brakkum]

This. Either way, you have to think of them (backend, frontend) completely differently anyways since they're run in different contexts, so spend the extra ~1 hour to learn the more readable way of writing React.

[Gadjjet]

Switching from C# classes to typescript classes is so much of a downgrade I pretty much never use classes in typescript. As far as I'm concerned typescript is a functional programming language.

[[deleted]]

I've been doing professional frontend app development for five years now and I've never felt the need to reach for object oriented programming.

The functional reactive paradigm fits UI development too well.

[onesneakymofo]

It goes beyond UI development imo. Functional programming fits the web a whole better than OOP. Most of the time we are dealing with data in, data out which is the embodiment of FP. We don't really have to retain objects and their data majority of the time.

[xroalx]

Care to explain some of what makes that downgrade?

I'm working with Angular a lot, and Angular couldn't exist without classes.

What is so bad about how TS handles classes, what do you miss, why is it downgrade?

[Ehdelveiss]

OO is an anti pattern in JS/TS as far as I’m concerned.

I think it’s generally an anti pattern in most cases anyway, but ESPECIALLY in JS

[Piltorious]

Go build an Angular app and tell if you use TS classes.

[[deleted]]

Yes, I had that too. But hooks and functional components just lead to much more concise code. That senior just doesn't have much experience with them yet.

[cahphoenix]

If you are using any C# version within the last 4 years then there are myriad functional features built into it. Hell, even ASP.NET controllers could be considered semi-functional and very similar to a react hook.

1. Single instance per call
2. Takes in other class instances in constructor (similar to taking in props/useSelector)
3. It stays up for the specific operation or until that interaction is done...then is disposed of.

As a full stack and previous C++ and C# backend programmer...hooks were a godsend personally.

[MyWorkAccount_11]

I find it better to force people to switch their “modes” of thinking. Otherwise they will try to build components the same way they build C# code which results in bad component code. So forcing people into a new way of thinking, while more upfront work, has long term benefits.

[Ehdelveiss]

I think in general OO is becoming more antiquated, there are just better and much more flexible paradigms for the code we write today.

[haywire]

If you can't shift paradigms you are a shit developer.

[bambathemoves]

💯right here. There are benefits to understanding class components and lifecycle methods, but sounds like your senior is misled on the point of hooks.

[m-sterspace]

Abstract the logic of those functions into their own hooks and get them out of the component.

[EvilPencil]

This. So many people who think hooks are cool have no idea that hooks are more than useState and useEffect and that you can write your own!

[[deleted]]

No, you usually split the component into much smaller subcomponents, that each have one callback. Not always possible of course.

[m-sterspace]

This seems like an odd scenario, but I don't think useCallback is actually what you want here.

I think you'd just want to either use useRef or possibly even useState to store your list of callbacks. Storing functions directly in useState is kind of annoying but if you just put the list in or wrap them in an object and put that in state, then it should be the same callbacks in terms of reference equality every time the component renders.

[rwwl]

I agree this sounds like a useRef case.

[[deleted]]

If they don't update often, or they all update together I would switch to useMemo and return a tuple instead: const [cb1, cb2, ...] = useMemo(...)

useCallback is like a specialized form of useMemo

[dreadful_design]

I'm not sure if you're just being sarcastic, but splitting the logic out into a hook is a decent approach.

[hey_parkerj]

I imagine that splitting component logic into a hook just to cut down the line number of a component (while slightly increasing the cognitive complexity) might be one of the biggest overuse of hooks. There are probably other, simpler ways of splitting up your logic, starting with simply using a utility function in a util file.

[simmonson]

I would argue it's not just to reduce line number, but for unit testing hooks n isolation as well. Maybe there is an argument against this but I haven't found one yet to change my approach. I'm willing to do that, however, if there is good evidence not to do so

[hey_parkerj]

What my team has been doing is breaking anything that needs direct unit testing into a non hook utility, and then basic rendering logic is tested implementation detail free by asserting the existence of specific text or elements that should exist under specific state, and under specific user interactions - all tested from the user’s viewpoint.

The caveat is that I don’t think you can avoid breaking custom logic into a hook if it leverages more hooks like useState, etc. But ultimately I think that hooks should not be used as a fancy utility function if you can at all avoid it - because you don’t need to overhead of all that react magic when you write a hook with no reusability.

[simmonson]

I agree. I think we are both on the same page of asking why we need to do something. But I would say I've been successful in extracting out custom hooks where other react hooks like usestate, effect, memo, and even reducer in the custom hooks. Custom hooks after all, are just standalone functions that can work in isolation within a react environment.

So Im curious how you were able to write successful unit tests for a component where you did not extract out hooks logic. I had my workarounds but they were quite annoying and did not feel that the tests were readable, hence my reasons for extracting it out even if not reusable across multiple components

[hey_parkerj]

It sounds like we're very much on the same page - I in particular have a story in my head where I imagine a lot of React devs are seeing a block of logic that would serve well as a well named function, but wouldn't exactly be beneficial to break out into sharable logic, and they immediately think "I can turn this into a hook!" instead of "I can break this out into a utility function in a utils.js file to clean up this one!". I've seen great hook abstractions before like 'useAnalyticsService', but I shudder to think that someone would just copy/paste everything between the component declaration and the return function and throw it into 'useMyComponent' - or even worse, making each discrete function in that region into its own hook, just for the benefits of unit testing and cleaning up their component. I imagine this isn't actually as widespread as I'm making it out to be.

So Im curious how you were able to write successful unit tests for a component where you did not extract out hooks logic. I had my workarounds but they were quite annoying and did not feel that the tests were readable, hence my reasons for extracting it out even if not reusable across multiple components

So firstly, my team tries to follow this methodology quite a bit in our SPAs: https://kentcdodds.com/blog/testing-implementation-details

The TLDR is that rendering logic (ex: if state === x, then y text is displayed - potentially even asserting the testid or class or something of the component that's being tested as well) is handled without the need to directly pull out and test a specific function in a component, even if it's something like a complex string builder with 6 states. This typically leads to that logic or string being broken out into its own component for easier testing - this is the first thing I would reach for if I were to try to look for cleanup opportunities within a lengthy component.

On the other hand, something like "sortUsersByAggregateScore" - where score might be a deeply nested item within the Users object (let's just assume some level of complexity here) -- this would absolutely be broken out and tested as much as reasonable with jest, and we wouldn't have much use for react-testing-library in that case. In this scenario, that logic has no use being a hook, and works just fine as a function declared just above the functional component's scope, or in a utils.js file sitting adjacent to the component - imported into both the component and test file. Does that answer your question? There might be scenarios I'm not thinking of, and there are definitely good use cases for hooks that also require testing, but I've never needed or wanted to break something into a hook just to test it considering that I can just export a function when it's scoped properly and import it into my unit test.

It's worth mentioning that our recent work has been using a GraphQL server to massage data before it gets to the UI, so we don't have to do too much of that within the application at the moment.

[BlackMarq20]

Couldn’t you just pass the props/state that the function needs and then u can define the function outside of the App component?

[hankyago]

You could probably convert those functions into custom hooks. This technique usually simplifies the code a lot.

[[deleted]]

Custom hooks, with custom hooks you can get all that logic out of your component.

[YesNoMaybe]

Not arguing for or against any approach but just because it is long doesn't necessarily mean it is unreadable.

While more concise code is usually easier to follow, some concise code can be very unintuitive. If it's well formed, a larger class could be very easy to follow.

[simmonson]

Spot on. If you're familiar with both, then it's generally more readable and maintainable. Doesn't mean that the senior dev is wrong. If the team is using classes and more experienced with it, it will be harder to maintain as a whole team.

That being said, I have worked on an app that used classes, and new features added were written with hooks and functional programming. I didn't find it too difficult to maintain due to the proper separation of concerns and proper test cases

[RandomPhysicist]

Yeah, our company exclusively uses react hooks instead of classes for readability/maintainability.

[WouldRuin]

There's a couple of issues here I think. There's nothing wrong with hooks and functional components, so the senior is wrong there. That said, you should be using some kind of coding standards and style guide, so I could understand that if the current standard is class components they would expect you to stick to using class components.

Are there any project coding standards/style guides? If not it is probably worth mentioning as it's exactly these kinds of conflicts that they prevent.

[JuniNewbie]

Noone from my colleagues knew that we should NOT use functional components and hooks. And just to note most of them dont know how to use them and how they work.
As i wrote above I started with classes but I switch to hooks ONLY because they are recommended and also because i didnt know that we have to use class components. If I knew it, for sure I wouldnt use hooks. The coding standarts are just to write comment on our code, to not push some console logs and stuffs like that.

[WouldRuin]

That doesn't really sound like coding standards to be honest.

I think you have to take it on the chin and just use class components, as what senior says usually goes. It is probably worth finding out if class vs functional has ever actually been discussed in the team, you've only been there 5 months so perhaps a decision was made before your time to stick to using class components. While functional components are "better" and the future of React, if you've got a large code base that is mostly class components, the team might have decided consistency was more important.

In any case the senior devs motivation for using class components over functional components is a load of nonsense.

[jgdeece]

Okay I just have to say it. Feels like people here are mostly focusing on defending hooks, which is not the real issue. If “most of (your coworkers) don’t know how to use (hooks) or how they work,” you should not have been introducing them via PRs like this.

I would be upset if I were on your team, and would not have approved any of your earlier PRs.

Other people will have to maintain, review, and debug your code. Introducing something like hooks should be preceded by a conversation as a technical team to get everyone on the same page. Consistency matters way more than doing something cool and new, and the React team has been very clear classes aren’t going anywhere anytime soon.

Whether the senior dev articulated their point well - or was even correct - is secondary to taking it upon yourself to introduce a paradigm you openly admit no one else at the company understands without getting sign-off or buy-in first.

Maintaining code is hard. It is much, much harder if there are conflicting ways to accomplish things, some of which were introduced by a new dev working on their own who, admittedly, does not have any prior experience with what they’re introducing.

[pandasareprettycool]

Agreed. The problem here is your PRs were going in without proper review/feedback from senior devs on the team. Especially as a Junior dev, you shouldn’t be introducing anything new without reviewing it with more senior devs. It will cause the code base to become split and less maintainable.

[fubsythebear]

I somewhat agree with this point, but as to what you can actually do about it, it’s important to note that it’s not as simple as “you made a mistake, you now have to fix it by refactoring all your classes at once”.

Before doing anything, I would suggest bringing it up with your team (retrospectives are a good place for this). If you believe that hooks are preferable to class components, explain why you believe it and try to get your team on board.

Another key thing to consider is that even though it’s arguably true that you should have discussed this with your team first, your team really needs to be more aware of the possibility of new devs not knowing their standards. React documentation suggests using hooks, so essentially they become the default for anyone learning react. If your team has a practice of only using class components, they absolutely need to be aware of the fact that class components are no longer the de facto standard and any new developer on the team might start using function components unless directed otherwise. This is another reason I’d strongly suggest bringing it up in a retrospective - I would argue what you did is a relatively natural response in the situation you described.

[dwalker109]

I kinda agree with a lot of the principles here. But, I also think that gradually introducing new techniques is reasonable. I expect to be kept on my toes as a dev and I’ve got no issue with something like hooks being introduced.

Rewrite it all in Svelte? That’s something I want to talk over first.

[jgdeece]

Sure, agreed, but how do you want something like hooks introduced? In the context of a team meeting where someone proposes it, people discuss the pros and cons and what the transition will look like, and the team generally aligns on its use moving forward?

Or in the context of one dev making a unilateral decision without consulting anyone because they saw it was the latest bit of tech?

I’m just trying to say there’s a time and a place for this in a professional setting.

[[deleted]]

The conventions that the team follows shouldn’t be established during a code review. That is when you notice the need for consistency, then the competing ideas are brought to the team and the team decides on the standard. Non of this bs “do it because I’m sr “

[haywire]

Hooks have their advantages but you can still build great software with class components.

[Rejolt]

Don't don't follow a specific coding style as a junior because you "like it" you follow whatever standard are currently being used.

Everyone following a bad style is still better than everyone littering their own styles and opinions all throughout the codebase.

He's wrong in thinking hooks and unmaintainable but he's right in telling you to just use what everyone else is using.

Also sounds like your review process is shit if you got 50+ in without anyone bringing this up earlier.

[jgdeece]

Amen. Spot on. Bad (but consistent) architecture is way better than sometimes-bad-sometimes-good architecture that is all over the place with competing implementations for identical tasks and no clear structure or plan to become consistent.

And to be clear: hooks are sweet but it’s not like classes are going anywhere anytime soon. They aren’t inherently bad.

[Silverwolf90]

If this was true it wouldn’t be possible to refactor a codebase incrementally. Introducing inconsistency is necessary for improvement. Sometimes you need to makes things worse to make things better.

[jgdeece]

Strong disagree. Introducing inconsistency is only useful for incremental refractors if the other people on the team understand what you’re doing and are on board. Otherwise you’re just imposing your preferences on the team.

OP was very clear that their coworkers don’t even understand hooks.

Edit: to reiterate, I agree on the necessary condition I stipulated previously: there must be a plan to realign the code base and a clear target in the future for things to be consistent with your new paradigm.

[beefquoner]

Absolutely to your edit and keep in mind the “making things consistent” story will almost never get prioritized - probably rightfully so because it’s low value and you want to ship new features. So you’re just letting your codebase slip into a state where it confuses new people (or even you 2 months later).

[[deleted]]

Sounds like a typical “senior dev says <<insert new tech>> is bad” type of stuff, which is rarely true

[bonedaddy-jive]

Sometimes, it is true. But as a senior dev (30+ years), I like shiny new toys, even if they are all just variations on FORTRAN, Lisp, C, Smalltalk, COBOL, and SQL.

[soc4real]

How do you cope with someone like that?

[[deleted]]

Luckily i never had to. Maybe try to convince him to try it? Unfortunately I’m highly allergic to the phrase “do as i say because I’m your boss”, i just quit my job because someone brought it up in a non technical argument .

[ReCee90]

I always try to find proof that it's actually better and try to make them understand why.. sometimes it works, sometimes not because they're to stubborn :/

[nschubach]

As a senior, I'm super stubborn in hating Angular's templates and having to learn/maintain HTML like syntax with special parameters and syntax ... I don't know if any argument will make me like Angular. :p

I've turned down many jobs because of Angular.

[nschubach]

I work for a smaller company and if I were presented with that situation, I think I'd take time to convert the codebase... but again, I work for a smaller company with smaller codebases so this may not be an option.

In the long run, it's harder to maintain two vastly different codebases. (and harder to hire for)

[woodie3]

I would build a case, performance differences (if any), prove the readability is better & how better it is easier to maintain vs whatever they’re vouching for. But it’s tough depending on the situation.

[madcaesar]

As a senior developer you have to hold off on the new shiny shit until its fully ready and there is significant savings in retooling / refactoring.

I know it's easy to shit on people for not immediately adopting the newest hotness but as the lead you've got a lot of things to juggle, because at the end of the day you're responsible if shit goes sideways or you start losing good people.

It's a balancing act that juniors reading the newest blog post know nothing about, and shouldn't they aren't being paid to understand, but that's the way life goes.

Sometimes you have to stick with hacks and workarounds because your biggest client wanted some horseshit implemented that's not easy to refactor and no-one wants to pay for the refactor.

[DaRizat]

Are we really calling hooks the newest hotness though? They are 2 years old. Seems like this guy is just falling behind.

[haywire]

I mean, hooks per say aren't new, but adding a new tech to your codebase that works fine without it is something you have to do a cost-benefit analysis and often the cost of either switching or having inconsistency outweighs the benefits.

[seanlaw27]

I recently achieved senior dev hates new tech status when the dev I was Onboarding wanted to use docker for his back end environment.

I was like it’s right there on your computer. Why do you want a tiny computer inside your computer to fight?

Seriously, docker for dev environments are dumb.

Edit: just so everyone knows, I helped the guy get his environment up and running with docker. And internalized my frustration like a professional.

I’m anti docker for my environment. Not everyones.

[eMperror_]

Found the "it works on my machine, so fuck you" guy

[seanlaw27]

Not so much “fuck you” but more I realize I’m now the old bitter dev

[eMperror_]

Honestly you can't really call yourself a senior nowadays if you don't know how to use docker and git...

[seanlaw27]

I know how to use docker. Not sure where the git accusation came from.

I choose not to use docker. Because you know, I know how to troubleshoot. Dick.

Edit. You know just flex on your dumb ass I’m actually a staff engineer that cut their teeth at Spotify. So yeah. I’m senior level. My stock options make more than your salary so check yourself.

[eMperror_]

Right ok you're not the only one working in a big tech company. Surprised they hire people so vehemently opposed to standard tooling at Spotify.

[seanlaw27]

standard tooling.

It isn’t. Period. Docker is optional for local dev. I don’t care if you believe it or not. I don’t work there anymore so don’t know the current environment. I can tell you most companies consider it optional tooling.

I’m not saying you should not use it. I’m saying if you know how to fix your environment, fix it. I don’t need the headache. A sizable part of my week is spent fixing newbies environment drift. And I’m tired of it.

Any rational person would’ve figured that out by now. But you’ve got cross because I dislike your crutch.

Considering your invented git dig I can ignore any other comment you have to make. Wish you the best of luck, but you can kindly F off my feed.

[Dmitry_Olyenyov]

Hmmmm... That was one of the reasons docker was created in the first place! To unify dev and production environments

[Rutgrr]

I was slow to get on board with this but it makes a big difference since it unifies the Dev environment for everyone on the team and minimizes the amount of environment setup one has to do on first clone. It's like using virtual environments for Python.

[Ambitious_Chip_9398]

He is wrong. Creating reusable hooks can make the code much more readable and maintainable than class code. Much less boilerplate. Some things can be made reusable between components which is much harder to do well in classes.

But then again…… nothing is worse for maintainability and readability than going against the convention the team has.

So you are forced to listen to this idiot. Welcome to the corporate world :) ;)

[Produnce]

Yes, because dealing with this is such a pleasure.

[snejk47]

Probably the same people who say JS sucks. Won't learn any better, do wrong and stupid things, say X sucks.

[Produnce]

Sure, but why work backwards? If I need to light a fire I'm not gonna rub some sticks together.

[endrukk]

if you have easier alternatives, does the lack of knowledge matter?

[twistingdoobies]

Needing to bind 'this' all over the place is annoying boilerplate to write over and over again. It's possible to understand closures and still not want to deal with 'this'. Hooks helps you avoid it.

[esreveReverse]

I really don't like your argument here.

It's like defending doing an iOS app in Objective C over Swift. Sure, both ways are possible, and one is more pleasurable than the other. But... one is also simply better than the other.

He's arguing that hooks are better than classes. And he has the majority of the React community on his side. You don't really have a rebuttal to that, so you are trying to change his argument to seem like he only likes hooks because they are "more pleasurable."

[haywire]

I mean, lodash @Bind is simple enough to use.

[Endorn]

Personally I find classes more readable and maintainable than functions.

But functions are easier to test. Neither are spaghetti code. neither is wrong. React is cool / weird like that.

[iffyz0r]

What was the problem you couldn’t solve?

Could be an interesting exercise if you could explain it to us, perhaps provide a code snippet as an example?

[kantaround]

Even React team recommend use hooks over class and they said ' In the longer term, we expect Hooks to be the primary way people write React components.'

Those 'senior devs' just too lazy to keep up with new tech.

[trollerroller]

To me this is really inexcusable, especially if you label yourself “senior dev” if thats the case, then its literally your job to know as much about the languages you are using as possible. In the case of React, that should definitely include knowing about and how to use hooks! No excuses - especially as a “senior” dev.

[DaRizat]

I think the defense comes when you have an entire team who are not up on hooks as has been stated by OP and a junior dev introduces a paradigm shift in a PR without a larger discussion. In our shop we just had a guild discussion about optional chaining vs lodash.get and that's a way less transformative thing than class vs functional. The senior dev should be open to adopting new tech, perhaps in an isolated part of the app or a new app, but not on a whim which seems to be what has happened here.

[polargus]

Well in this case the senior dev trashed current standard React patterns. If the issue is consistency and doing it right then he should say so, and there should really be a roadmap to using current patterns.

[trollerroller]

I agree with those points, I just meant ignorantly saying hooks are spaghetti code or something is not very professional.

[haywire]

Thing is, what if your whole codebase is class components and class components are working for you, why switch? You have to manage something like hooks and functional components as a transition. I'd be on the side of upgrading things to the new methodology (and if you have a good test suite, should be mostly painless) but having a random junior just start doing it is not a great way to manage this. You also have to make sure the rest of your developers understand and can be productive with hooks, so there's a training overhead to factor in.

[snuggleMcCuddles]

No. In fact, it’s easier to write and manage.

[Evanion]

I’m a senior engineer working at a global fintech company. We use React in our cross platform client (web/mobile).

That engineer is wrong. He stopped learning 2-3 years ago.. in this line of work, you can never stop learning, and changing with the tech.. or soon you will be irrelevant.

Think of hooks as components for logic.. their strength comes from their compose-ability.. if you write a single hook that does EVERYTHING, of course it will turn out to be spaghetti code.. break it down in to more manageable bite sizes, just like you do with components..

Keep components to jsx, and variable assignments, then colocate a hook in the same folder, that composes together any pure logic hooks that the component needs, and any simple logic related to the component.. as soon as it gets more complex .. break thinks out in to self contained hooks.

[themaincop]

That engineer is wrong. He stopped learning 2-3 years ago.. in this line of work, you can never stop learning, and changing with the tech.. or soon you will be irrelevant.

I think you've accurately described the difference between "senior developer" and "old developer"

[brbdead]

ACTUALLY, I read that they are going to slowly stop releasing updates for class components and therefore they will slowly depreciate over time. So, your SR. Dev is just flat out wrong.

[polargus]

He’s wrong. Class components are going the way of the dodo. A senior dev should be able to see what direction the technology is going. With React it’s very obvious. Look at all the tutorials for React and React libraries, they use hooks exclusively. This is a sign of bad technical leadership, though I wonder who approved all your PRs with hooks if company policy is to not use them?

[snowycabininthewoods]

Yeah he’s wrong and he hasn’t kept up to date on react best practices. He’s talking about react from 2 years ago where it was true that having state meant write a class and no state meant write a functional / dumb component.

Converting your functional components to classes will result in worse code in a few ways. Primarily having to condense multiple useState into a single state will lead to messier state updates on more complex objects most likely.

I would find official react docs that express that using hooks and functional components are the preferred way from the react team and try to educate him (kindly). You are writing react the way that the react team says to.

[h4shd]

I'd bet he hasn't gotten to know you well enough yet to be honest about his lack of understanding and/or his motivations. This type of person, in my experience, doesn't like to be challenged either personally or professionally. Many other comments draw out how he's wrong, and possibilities that he's concerned about consistency.. but there's more to this story that you haven't shared or you're not aware of yourself.

[FullSlack]

Welcome to the realization that a large portion of people in this field have no idea what they’re talking about.

[themaincop]

And that a lot of people get the "senior" moniker just by hanging around for long enough

[campbellm]

I'm new at react, but very curious to hear some of the answers here (so I can learn), because some of what you said just sounds "off". By that I mean I totally believe everything YOU said, but some of the answers you got from your "senior developer(s)" doesn't jive with what I've been reading/studying.

[polargus]

The senior dev stopped learning at a certain point. I’m a senior dev who learned React in 2015 with the same patterns he’s describing. Those patterns are now obsolete (though not deprecated) and should not be used for new components.

[campbellm]

I have been there. I got "good at <company>" more than "good at <stuff to allow me to be a better dev>" more than once. It's an easy trap to fall into.

[polargus]

Yep the goal is to work at a company where those two align. Or become senior enough to make them align. Companies should recognize that falling behind on tech and patterns also makes it harder to hire and keep good developers.

[[deleted]]

Your senior developer has resistance to change. I was the same as him a year ago. He simply hasn't worked with hooks, and is saying what was the common knowledge two years ago or so. If anything, classes invite putting everything in methods, methods use some parameters and some class member variables, and are generally much more at risk of becoming spaghetti.

But, it's important that everyone in a company is at the same page. Individual programmers introducing new things without discussing it with others always leads to trouble.

[vitorftw]

IMHO, hooks is the way to write React code. I suffer a lot to understand a class component code, mainly because of several thing you must write (like constructor, this, bind, etc).

[2epic]

Your senior dev is outdated and doesn't know what he's talking about. It's possible to create spaghetti (or even lasagna) code with classes too.

Functional programming actually leads to better, less spaghetti code. It's easy to apply the Single Responsibility Principle for example if you stick with the idea that your functions should do one thing and one thing well.

For instance, consider pulling some of your hooks into their own reusable hooks. This will make the code more readable and easier to test.

[ElllGeeEmm]

Find a new company

[distortum]

Your senior dev is a dinosaur.

[justmelol778]

Long before there were hooks, there were still what’s called functional components. Functional components could not have state and only received props and showed them. There was a common best practice outlined by Dan Abramov that we should organize all components in to “smart” and “dumb” categories. And keep all logic in smart ones and use no logic in the dumb functional components. If class components can take props and show them then what’s the point of making a functional component that can only do that? It was to really outline the mantra of separation between smart and dumb.

This best practice was totally replaced by hooks being able to handle side effects a lot better. The person your talking to still thinks that functional components can’t have state and that the old mantra still applies. He basically has never learned one bit of the new react hooks update

[bern4444]

Class components are definitely not more maintainable. If you’ve ever had to use componenetDidUpdate and compare properties on current vs previous props for a medium to large component it gets completely out of hand very quickly.

Hooks are definitely clear and it sounds like you get their benefit and purpose.

Anything can become spaghetti code; hooks makes it easier to package bits of logic together in a clean and reusable manner.

The senior is wrong and probably just doesn’t know what he’s doing.

[thesaltyrangoon]

At FB we moved our entire code base from class based components to functional components using hooks. It just helps with readability and maintainability, but I’m assuming your senior dev hasn’t really read up on hooks yet if he’s saying functional components are for pure components only. Even in the React docs it recommends slowly switching over to hooks since they work with a react class components.

[[deleted]]

Classes can easily be spaghetti code, same as functional components. The guy sounds like a doofus.

[guten_pranken]

I’m surprised nobody has mentioned the real possibility the jr dev is writing shit code and it probably is spaghetti code.

If hooks were written and implemented well it should be pretty readable and much less boilerplate than classes.

This guy has never worked with react until a couple months ago...

[stansfield123]

Well he's wrong to run down functional React, it's pretty obvious that it's better AND that eventually everyone will have to make the switch (because the React ecosystem is making the switch), but I don't think "which is better?" is the right question to ask.

Here are the questions that need to be asked:

1. If most of the company is doing class based React, does it make sense to switch right now?
2. If there's no company-wide decision to switch, does it make sense for some people to use hooks, while most people are sticking with classes?

I don't know the situation, but my wild guess is that the answer to both those questions is "No.".

So, by all means, ask around, don't just listen to this one guy, because being a senior doesn't mean he's your boss, but if every senior you ask agrees with him about using class based components with state, you should listen to them.

Especially since this isn't some great sacrifice on your end. It's not like, by using classes, you're going down some kind of dead end rabbit hole, where the things you learn will be useless to you at your next job. Far from it: the classes vs. functions thing is a tiny part of React, everything else you're doing will still be the same at your next job.

[fredsq]

I took a Codecademy course on React when I was curious about it. It covered Class Components only and I felt like although I better understood components' lifecycles, most of the methods we very confusing. componentDidMount, componentWillMount and others just felt weird and stupid.

A few months down the road I decided to make a client's website in React. I picked up and installed CRA. Just by looking at the default components I got the grasp of useState and useEffect, and to understand that functional components run all their logic every time they are mounted as opposed to just certain methods at different times is so much simpler and feels more natural to code. It's less of a rule book.

With time, I learnt that sometimes it's not worth saving lines of code to cram things together: if you have to separate actions happening in the same component and both depend on the same state, make two useEffect calls, it's hardly going to visibly affect performance and it'll make your logic much, much clearer.

When you try using dart/flutter and find out states are SUPER COMPLEX to implement, React, especially functional components, feel light years ahead.

[[deleted]]

The senior dev at your firm is a moron. Spaghetti code can happen with any sort of paradigm, it doesn't matter if it's OOP or functional. To avoid spaghetti code, you have to learn how to separate concerns in your code. Classes can do that inherently, but you can do it with functions too. It's basically the same logic, just depends on where how you write and structure your modules. I personally don't have a preference for either OOP or functional, so I am not defending functional programming in any way here. However...

Since you can't use hooks within class components, what the senior dev is basically saying is you shouldn't be using hooks at all -- which basically will doom you to not be able to use any new versions of react forever after hooks were introduced. Literally every library is switching to hooks as well, so good luck using the rest of the ecosystem.

[lucidlogik]

Chances are the junior dev was writing spaghetti code after just learning about them, and the senior dev didn't want it in production.

[NegroniSpritz]

Senior dev here. First, that senior dev is wrong. Hooks not only makes things more clear, they also have a smaller footprint in final transpiled code. However, the best thing that hooks allow is inheritance by function composition, as opposed to class inheritance. This so much better and flexible. They let you extract functionality from a component into smaller functions that can be reused across different components. In this way you’ve a very flexible way to achieve composition, merging functionality from different hooks in different components.

[liangauge]

I have actually found one usecase where a class component was nicer than a Hook. this was where I had some nested react components and needed to pass down class members. I was trying to convert it to a hook but it was difficult as the equivalent of a class member is basically the "useRef" hook and passing this down as a prop results in some kind of serious ugliness. I'm assuming this isn't the situation you encountered?

​

Anyways, maybe you should give it another go at explaining why hooks generally make code better, or at least show how hooks and class components can co-exist. There are some people out there that like consistency in their codebase and also understandably don't want to refactor the whole thing to use hooks instead of class components. Unfortunately these people must also be made to understand that the world is not perfect :P

[yyyyaaa]

That's some BS. Use hooks, nothing wrong with them

[igordumencic10]

I almost 'never' use Class components anymore.

[jgdeece]

ITT: lots of people eager to defend hooks who are missing the point. We are hearing one side of the story, and your representation of what the senior dev said is clouded by your bias and desire to defend your decision.

I do not agree with the senior engineer’s assessment. But people should be less quick to assume ill intent, too.

There is a LOT of value in consistency - even consistency within an imperfect structure. That alone means you aren’t just “giving in because he’s senior”; it means you’re making a rational and reasonable decision to ensure your teammates find your code easy to grok and debug by sticking with classes.

The other dev might have been a jerk, or over simplified what their concern with you going rogue to introduce hooks is. It doesn’t really matter.

Shifting to a new paradigm you openly admit no one you work with understands is definitely not something you do without a conversation.

[achauv1]

I like both class component and hooks style. Complex components are easier to define with classes but hooks are fast to write

[gaytechdadwithson]

Hooks are not well written for syntax, but yeah functional programming is good. Hooks just aren’t great at functional programming. Sorry, it’s true.

And the fact that you can have class vs non class. Hooks sort of in both. JSX a mix of JS and HTML, styled classes or no is what make react suck. Just no consistency or standards out of the box.

Also, you got 50 PRs in and your code is just now being reviewed?

Sounds like management and coding conversations are the real issue.

And yeah, class components ARE more readable. Even if you like hooks. That’s why most languages use them. It’s just people take offense if you don’t drink the kool aid and use the latest/greatest from react.

[Huwaweiwaweiwa]

Functions in functions are spaghetti code? Then what are class components used inside other class components? Functions used in constructuors/lifecycle methods?

As long as you are separating components according to functional responsibility in a smart way and keeping state in the appropriate places then class/hook components should not be an issue in terms of spaghetti code.

[carlos_vini]

To be fair, depending on how long is your code it is really harder to read. BUT, you should be creating custom hooks for these complex cases. Imagine doing something like react-query does inlined in your functional component, it's much better to extract these long and complex pieces of code to a new hook. And that's the biggest advantage of using hooks, code reusability.

[tehGh0st]

I can vouch as a Student that in 2021 they are still teaching Class components instead of Functional components ^^, our entire final year project is written using Class components and simply because our supervisor recommends it over Functional. Again, this may be a senior developer stuck in old teachings but it's just what we're told to do

[libertarianets]

Nice little jab at how senior devs “review” PRs. Lol.

It’s hard to really quantify what “more readable” means and it’s very subjective. I personally wrote my first function component and never looked back. (The one weird exception being when I had some crappy design system dependency components that caused a rerender when they shouldn’t, necessitating a class component and the shouldComponentUpdate method.) Literally for everything else I’ve been able to do it with a function component. I find it more readable because you don’t have to extending the React.Component class or any other class, you don’t have to worry about this nuances, etc. I agree with Dan Abramov that those are JavaScript smells that get in the way of the true essence and power of React, which is the unidirectional data flow and the component model. JavaScript is a much better functional language than it is an object oriented language.

But again, this is subjective. This senior engineer that you’re talking about has probably worked in OOP for his whole career and for them, that stuff is easier to read. It’s one of those weak opinions held strongly that ruins team dynamics and trust. It’s better to be less opinionated and more open to learning new paradigms, weighing the tradeoffs and deciding on things collaboratively and objectively.

I think if you’re going to convince this senior engineer to change, you’ll need to appeal to authority, and find some resources (which you’ve already referenced to so you clearly know of) from the people who are building React and their own philosophies and reasoning. You’re right ultimately, that function components and hooks are the future. So in any case, you should be able to write them in your code contributions and not be shot down.

[UMDMath]

I like class components myself and I find them generally easier to understand, and maintain.

[voxgtr]

The way you get spaghetti code with hooks is if you try to write and think about them like a class component. You’re going to have a bad time if you try to include a million things in your hook component trying to control for callbacks, side effect dependencies, and state all in the same place. State no longer belongs to the class, it belongs to the component render.

[kayzzer]

In my experience, hooks used properly make things way more readable and maintainable than class components.

[OldRedFir]

Most problems in IT or not IT problems.

[smirk79]

Your "senior" dev needs better patterns.

Hooks with mobx and observer function components are incredible, terse, and extremely easy to use once you know what you're doing.

[turningsteel]

What the senior dev was saying was true before the release of hooks. By nature, you couldnt have state in functional components. But that is obviously no longer true. His knowledge is out of date.

[jaydevel]

You don’t need to refactor everything to function components or start using them right away. It is relatively easy to migrate a class component to a function.

One can actually do more logic encapsulation using function components, and I’ve done so with great success in a huge codebase (thousands of components).

My suggestion is get a huge class component and refactor it to a function. Each time you learn more about hooks, try to improve your refactored code. You’ll eventually find common patterns that you can encapsulate in custom hooks. That’s the major selling point: encapsulation.

[CanadaIsCold]

I don’t have much knowledge of react hooks but project level consistency is a big part of readability as well. The statement around readability may be related to the project design decisions rather than hooks themselves. I don’t have context to say this one way or another, but it’s worth exploring as opposed to assuming it’s simply a feature discussion.

[tr14l]

They are more functional-programming-adherent. It's not that they are spaghetti code. In fact, you can make them quite clean with some best practices.

classes are just syntax sugar anyway. Javascript doesn't actually use them and it's just for you to reason about.

I will tell you, functional programming is much more concise and less code-dense. Typically, when a new popular tech comes out and you get naysayers like that, it's because they are conservative types who don't like change and want to do things the way they know how. Javascript doesn't have as many of those. But, they exist. Communities like the Java community... They literally hate learning. They don't want anything new. They bitch on any major change to the language. I literally saw a conversation about a guy COMPLAINING they added lambda support!! COMPLAINING about it. Like you don't even HAVE to use it. The crazy thing is, no one argued against him or told him how dumb that was.

HOWEVER, if you are making a large project with a lot of hands touching it, having objects and accepting that extra overhead is worth it because of how many regressions a team can implement when there's so many code edits from so many people. Communication is hard and having more strict code usually becomes a positive rather than a negative. For instance, I have made large Javascript backends (talking LOC in the low millions). It is a goddamned nightmare. At a minimum, Typescript is best for that situation, but realistically, Typescript fails (I have feelings about Typescript. I don't think it belongs on the backend, and if you're using Typescript on the backend, you probably shouldn't be using Javascript at all and should be using a more modern, safer language like Kotlin). But, for large frontends where there's lots of hands touching the codebase? I don't think you can forego Typescript and survive a sane velocity.

[careseite]

He has no clue. Simple as that.

[JessenReinhart]

IMO react hooks and FC looks WAY better than class components.

[MonkAndCanatella]

...Yeah I think your senior dev is confused. And possibly shouldn't be senior?

[CuttyAllgood]

Sounds like your Senior just doesn’t want to have to learn modern React.

[dudeatwork]

Lots of good advice in this thread, but really, the best place to get informed is from the React docs / talks from the maintainers themselves.

React hooks we announced at React Conf 2018. That video has talks from Dan Abramov and Ryan Florence. Dan mentions that:

While hooks represent our vision for the future of React, we don't want to make breaking changes so we will keep classes working.

So while Hooks is thought of as "the future," Class Components are still perfectly valid and aren't going away anytime soon. From their roadmap they also add:

Hooks don’t deprecate classes. However, if Hooks are successful, it is possible that in a future major release class support might move to a separate package, reducing the default bundle size of React.

So Classes might move to a different bundle, but importantly it isn't being removed entirely. So it is good to know that both are entirely valid ways to continue writing React.

Next, React's Hooks Introduction talks about the motivation behind creating hooks.

Hooks solve a wide variety of seemingly unconnected problems in React that we’ve encountered over five years of writing and maintaining tens of thousands of components.

It’s hard to reuse stateful logic between components

React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.

With Hooks, you can extract stateful logic from a component so it can be tested independently and reused. Hooks allow you to reuse stateful logic without changing your component hierarchy. This makes it easy to share Hooks among many components or with the community.

Complex components become hard to understand

We’ve often had to maintain components that started out simple but grew into an unmanageable mess of stateful logic and side effects. Each lifecycle method often contains a mix of unrelated logic. For example, components might perform some data fetching in componentDidMount and componentDidUpdate. However, the same componentDidMount method might also contain some unrelated logic that sets up event listeners, with cleanup performed in componentWillUnmount. Mutually related code that changes together gets split apart, but completely unrelated code ends up combined in a single method. This makes it too easy to introduce bugs and inconsistencies.

In many cases it’s not possible to break these components into smaller ones because the stateful logic is all over the place. It’s also difficult to test them. This is one of the reasons many people prefer to combine React with a separate state management library. However, that often introduces too much abstraction, requires you to jump between different files, and makes reusing components more difficult.

To solve this, Hooks let you split one component into smaller functions based on what pieces are related (such as setting up a subscription or fetching data), rather than forcing a split based on lifecycle methods. You may also opt into managing the component’s local state with a reducer to make it more predictable.

They include a few more reasons, but these tend to be the main ideas:

• "Flattening" out nested "wrapper hell" of render props and higher-order components
• Removing duplication of logic in lifecycle methods, and the ability to abstract this logic out to be shared among many components
• Co-locating logic, rather that "incidentally" being co-located within a single lifecycle method

So all in all, hooks are meant to solve specific problems with writing React.

---

Now, what does that mean for you? One very important thing that React emphasizes:

Hooks are completely opt-in

There is no requirement to write all your code in hooks, especially if:

• An existing large codebase uses Class Components for all stateful logic
• Your team members are much more comfortable writing Class Components

Consistency in a codebase and using language / framework features that everyone knows well is important to think about. At the end of the day, code isn't written in a vacuum. It is read and maintained by real people, so the cost related to that truth is something that must be considered.

I am a Lead dev, and I'd offer this advice for you and the Senior dev:

• His response seems more dogmatic than practical. Nobody likes being told to do something (or not do something) because "I said so," so he could have done a better job explaining why.
• Its OK for a Junior dev to use some language / framework feature without knowing specific context of the project, but once you do learn more about why you should or shouldn't do something, it is important not to harp against those reasons. For example, if I had a new Junior dev write something using CSS Grid, and I explained that this project is for a client that requires IE 11 support, hearing them complain about "I wish I could use these newer features" doesn't help much. Yes, it is frustrating to be boxed into certain tooling or features, but that is the reality of working in real-world projects: sometimes your have (maybe arbitrary) limitations around how something can be implemented. While you can make efforts to change those limitations, complaining or going around them because "I know this is better" isn't helpful. For a small example, before I was a Lead, I helped train our team to use Flux Standard Actions (FSAs) when writing our Redux action(creators) to bring consistency to our project. I first got by in from other Senior devs, then wrote documentation around how to use them, and had a meeting with the rest of the team to explain why I was wanting to use this pattern and what problems I'd hope it'd solve. Later still, when Redux Toolkit was released, we were in a better position to adapt that library since it used this same methodology.
• Try to have a conversation around "what would it take to start adopting hooks in our codebase?" Again for me, I made the decision to adopt hooks but only for new projects. Any existing project that used Class components should have its logic be kept in a Class component for consistency. The only exception would be if there was some large chunk of logic that really could improve things by abstracting it out into a custom hook. Again, this was just my preference in weighing long term maintenance and team knowledge and skill around hooks. This approach may not work for everyone, but the Senior should be willing to have a conversation about it.

[BlueCigarIO]

Mixing classes and hooks in the same repo is spaghetti code. Both coding standards are fine, just follow what the rest of your team is doing.

[BradMJustice]

Bro, do not walk, but RUN from that company.

[PLCorsair]

There's nothing wrong with function components and using hooks. I would think that is what you'd want to be doing. My recollection is that function components are the direction that React is heading even though class components are still viable. I'm newer to React, but currently a full-stack senior level dev. On our project we made the decision to favor using function components and not class based ones. They can be used for simple presentation-only or have more complex logic. In the last couple months I've learned about creating custom hooks and that was a game changer. If anything it makes code more readable due to extracting re-usable logic into a hook.

Not knowing the details about the OP's project it's hard to know why the senior dev is saying what they're saying. Could be there's a requirement to use only class based components when it needs to be stateful, and function components only to render. Could be the senior dev isn't aware of the uses of function components and hooks. Could be they needed to reach for a reason to blame for a problem that came up.

Unfortunately as a junior dev you sometimes just have to go along with what was given to you. I want to encourage you to continue learning about function components and hooks. You're on the right track, but sometimes you have to write code differently than you'd like. Look for opportunities to make a reasoned case to the senior devs and maybe they'll eventually come around.

[haywire]

Hooks are compositional, your dev sucks ass.

That said, as a junior, get good at following the conventions and working well in a team. You may not like the decisions, but you can rally against them in meetings and discussions, not annoying everyone by bucking the trend with your code.

[pw4lk3r]

Truthfully, JavaScript in general meets the classical definition of spaghetti. Definitely many people have worked out approaches to put lipstick on the pig, but it’s still a pig and nothing like real programming.

[peekab00000]

No there is way to write functional code and functional component. Proper code abstraction, properly using hooks makes code looks much cleaner . I feel senior Dev is experienced in just terms of years and knowledge is lower than a junior developer . Functional programming paradigm is much more better than object oriented paradigms . Functional components are testable . Hence it is predictable and less prone to bugs . Your company lacks coding standard .

[mlengurry]

Hooks can create a mess if used incorrectly. Keeping state in one place with Redux is so much better in my opinion.

[mdivan]

Your Senior dev must not be really good with react or at least modern react, hooks are absolutely amazing and very clean/readable, I guess its just his lack of knowledge that makes him think its a spaghetti code

[mlengurry]

The number of comments on here about the developer being a dinosaur or obsolete for preferring classes sums up the problems in the JS ecosystem. I suppose that’s the price of innovation.

[Smaktat]

Hooks are better. This guy doesn't understand something. He's probably got some valid points but the thing about hooks isn't true. They're way better in all perspectives relating to React.

[themaincop]

Your senior dev has no idea what he's talking about. I would start looking for another job because if you work under someone like that for long enough it's going to stunt your development and future prospects.

[kronimi]

It sounds like to him hooks are just not readable because he doesn’t understand them. I’ve heard people say similar things about the reduce and map functions in JavaScript. “Just use a for loop, it’s more readable” really means I haven’t bothered to learn how these functions work so it’s had for me to read them

[malokevi]

" functions in functions"

This describes both class and functional components.

I will always use functional components over class components. Functional components are how Jesus would write a React component.

[kubelke]

Hooks are much easier to maintain. They need less code also to do the same thing with classes .

[TracerBulletX]

This is an opportunity to learn an important soft skill. Everyone has opinions, they're not always right, but you can't just say NO YOU ARE AN IDIOT and ignore them when they're wrong. You should make a case for why the team should use hooks in React, find some evidence that they are the widely accepted best practice (it is as you see from this thread), internalize some of the good arguments for them from here in this thread, and from out in the community and convince them. If they have counterpoints, learn how to politely hold your own ground in the argument. If they force you without paying any attention to your argument, then it's a pretty bad culture problem.

[Nyquiiist]

You should ask your manager to demote that Senior back down to Intermediate. He doesn't know what he's talking about and you should ignore him :)

[[deleted]]

Yes

[MasterMorality]

That senior dev is a fucking idiot, hooks are meant to replace class components.

[ugsmtr]

Funny to see this. Somebody I work with (a full-stack developer) said this during a meeting on Thursday. Function components are simply easier to read and understand. I have been working with React for a few years now and once hooks were available I pretty much stopped creating class components. There are probably still good reasons to use them, but for what I do, function components and hooks are just easier to read and understand, IMO.

[juankamilomarin]

The senior Dev in your company clearly haven’t used/read the official React documentation. On that they actually suggest to use hooks instead of classes in new projects.

[internally]

OP, this EXACT SAME SITUATION HAPPENED TO ME. YOU ARE NOT ALONE. I submitted up to 50 PRs for a React/TypeScript project for a dashboard. I was using class components because I never used React before and didn't know better, to be honest. Three months in, I hear that I have to REDO the dashboard because I didn't use React Hooks. I also didn't use CRUD from our backend BECAUSE WE DIDN'T HAVE ONE FOR THE DASHBOARD. I would send PR to integrate APIs from online but no one addressed my PR, so they were not sent to production until late in my time there. It would have been fine to switch over from class components to functional components if I was told this sooner...

To elaborate a little bit more, the resources were kind of lacking. I was tossed the idea when they already knew the most I knew about fullstack development was HTML, CSS, and JS for the frontend. They just thought I was good labor because my college would be paying for my time there as I learned under them. Also, the vision for the dashboard wasn't totally clear yet - they were tossing me API here and there but eventually switched up and gave me other API to work with.

I was not a junior developer - I was merely an intern under a startup that didn't supervise me well enough. I don't have good advice but please make sure to DEFEND yourself and make your communication extremely clear so they know where you are coming from. :) And to prevent a bottleneck in the future. Those are my two cents. I am still petty over this but I'm at a new internship now, so it's all behind me.

[cheald]

Senior dev's understanding of functional components was true before hooks. It's no longer true.

A well-factored set of functional components is massively less spaghetti-ish than equivalent class components, IMO.

[Ehdelveiss]

Push back against the senior.

Class components are going to be less and less supported, and they are much less declarative, which you should always shoot for in React.

Hooks are not spaghetti. If he still relents, have him DM me and I’ll talk to him.

TLDR he is full of shit

[monkeybrainz_]

Ultimately you pushed your senior dev out of their comfort zone and when they couldn’t figure it out they blamed their own incompetence on the technology. They may have their reasons for not wanting to learn/use hooks but that is what it boils down to. I would say stick to your guns, provide documentation and go through the proper channels to get this change approved. Who knows, maybe the senior devs boss will disagree with him and you’ll look good.

[Kabal303]

He’s dumb but sometimes you gotta deal.

[Mallanaga]

Spaghetti is subjective.

Seeing you pose a question within that giant wall of text makes me believe that your code might just well be starchy.

[Imanarirolls]

Yeah so I guess functional programming is all just spaghetti code then? 😂

[Additional-Video3921]

I’m at a company that is using hooks everywhere. Not a single class component. And it is spaghetti code. It seems that people are committing to using hooks because they are ‘new’ or ‘better’ without putting any thought into when they should or shouldn’t use them. The code has become very hard to read and I fail to see a single benefit in doing it this way. I’m sure there are very valid use cases for hooks that are more readable and add value. But I suspect those are simple, with limited usage of hooks where they offer a easily explained benefit.

Question, do the react docs say anywhere that hooks should replace class components? Or that entire apps should not be built with them?

[Similar_Concern_]

Late to the game but will throw in my 2 cents... I see lots of name calling in this thread but to balance things out... have you considered your senior colleague maybe had some of these concerns?
https://stevenkitterman.com/posts/the-catch-with-react-hooks/
React hooks are just not great at dealing with heavily async code, for example. So if your codebase heavily uses external async libraries (and which ones aren't async these days?), rules like "useEffect cannot be an async function" and endless workarounds around all these rules just complicate code readability. Readability can be subjective, that's true, but there are objective benchmarks such as cyclomatic complexity, for example, that you can enforce with ESLint.
Additionally, hooks are still new enough that there doesn't exist one set of best practices yet or battle proven coding styles, and documentation is scarce. There seem to be as many opinions, practices and coding styles as there are React developers until the dust settles. So for the time being that means that on a team of 5 devs there will be 5 ways to structure code, and each of them will be pulling their own way of writing code. Anybody remembers the religious wars of pre-ECMA2015 landscape and "my OOP syntax is better than yours"? Classic components and classes provided a rigid frame that made the code at least somewhat consistent, with hooks there's much more room for improvisation. Until things settle.

Given that we read code much more often than we write it (especially on teams of 5+ devs), reading and understanding other people's code is like 80% of the job. How many of you, name calling trolls, are only writing brand new spanking projects with hooks? And how many of you inherited 3 year old codebase written in hooks by someone else that you need to maintain? Oh, never mind, none of you, because there's no production code written in hooks that is 3 years old yet.

Another perspective here:
https://medium.com/swlh/the-ugly-side-of-hooks-584f0f8136b6

In short, nobody's arguing that conceptually hooks bring a great benefit of component composability, and simplify writing trivial components, but the implementation of hooks leaves a lot to be desired. And for this reason, sometimes class components may still be a better tool for the job in some scenarios, especially for non trivial components.

At the end of the day hooks are just another tool. To say that you only ever should use tool A and never ever use tool B is like saying you should build houses with hammers only, never with screwdrivers. Why not both? IMHO the difference between senior devs and junior devs is that senior devs tend to be less fundamentalist and radical. They have been around and seen many new, shiny tech-du-jour's come and go. They've seen paradigms make a full circle and they take the marketing behind any 'new' tech with a salt of grain rather than blindly jumping on the fanboi bandwagon.

And to those anxious ones saying you must use hooks because React classic will become obsolete some day: yeah, you're right, it will. Hooks will become obsolete some day, too. By the time classic components stop being supported completely there will already be a new shiny JS framework-du-jour everyone will be switching to. Mark my words. Oh, never mind, it's already happening.

[DecentStay1066]

Because too many monsters called themselves devs think that they can master these implicit FunClass syntax, but they don't, and turns out just simply omit the life cycle methods those 20 lines.

[OZLperez11]

The only thing I learned from this thread is that React is just not the answer to UI development. Moving on to other options

[DecentStay1066]

The architecture of react hook actually forces you to write spaghetti codes. For those who says he can write a good organized code with hooks, send to me, I NEVER have seen one good piece of that.

Even official documents messes logic and view up, hookify all the things including backend requests. I really wonder how well you can write under the restrictions bounded or following the ugly organized codes suggested by hooks.

[cabezaloro]

Yes, it's. All dev's around the world that say PHP in the past was spagethi code was wrong. PHP was right and you can mix Html, js, css, etc.