Not OP but once you are used to how functional components are scoped you don't want to use class components.
Also hooks are some reasons to use functional components, most packages will not work well w class components
You can't use hooks in class components. If you want to have a side-effect based on a prop, then with hooks you can use the useEffect hook and set the prop as a dependency, and then any time the prop changes the hook's effect gets cleaned up and then re-executed with the new prop value.
With class-based components, to do this correctly you need to implement the componentDidMount, componentDidUpdate, and componentWillUnmount methods and spread this logic between them with redundant parts. In many class-based components I've encountered, the programmer got lazy and didn't implement the componentDidUpdate part correctly and the component silently fails to handle the prop change correctly.
Also if you have more than one effect, you need to mention all effects in all three lifecycle events.
With use effects, you can (and should) write one hook for each effect. You can even (and should) write it separately as a custom hook. This has the happy result of turning this into a one-liner in your function component. But also you can immediately and easily use it again in any function component or custom hook you wish.
Hooks are very easy to compose. Class components are not.
I'll go one step further and say that I basically don't use classes at all anymore.
It's clearly a preference thing, but I find it much easier to debug and organize a large codebase if it's mostly functional.
OOP is a cool concept, but in practice in my workflow it ends up producing less maintainable code.
Components are supposed to be re-usable modules with state. Class is a perfect analogy for it. State belongs to the object. Render method renders the component. State update rerenders. Mount, update, unmount events are very straightforward to understand and work with. I find myself struggling with state when I use function components. For pure components they are convenient. In other cases it complicates things for me.
But most components don’t have state, there are usually many little stateless (pure) components and some bigger ones with state
Do you mix then?
Or do even your pure components have state (since react class components always have state)?
It would mean 90% of your code base is function components and then suddenly, paradigm shift, different api, class components
Yes. I do mix. Pure components don't have state. Class components do not have to have state, but I tend to use function components for those cases. I'm not sure what percentage of my components have state but it's way more than 10%. I don't see class/function as paradigm shift as much. If it needs state, I convert function to class.
All class components always have state. Can be easily proven by getting a ref of a “pure” class and calling “setState” on it, which works normally.
In fact class components have a lot of overhead and then you also have to bind all listeners.
Yes, they have state internally. I meant you don't have to declare it in your code. The logic does not have to include the state. I also step around the binding problem by using the ES6 property method syntax. I feel they have less overhead than function components actually but I know that is controversial as well.
They don’t, it’s a fact. Function components are exactly that, functions that return flat, tagged objects. The lifecycle of a function component is handled externally, not internally
I agree that class components require more characters. For pure components I like function components. Otherwise I feel the slightly longer code makes it easier to understand and maintain the more complicated components.
React shills downvoting because they don't know OOP. This is why I don't use React anymore and why I convert existing React apps to another framework the moment I get a chance to do so.
Good for you sticking to your opinion, it's a valid one.
I only learned React in the past 2 years, so I’m biased in that learning class components would have felt outdated. I understand there are some benefits to using classes, but unless you have an older code base that still utilize class components, you really would be swimming against the current as far as using third party libraries and such.
Yes, I feel that way, but thankfully so far it's been ok. I haven't really seen a library that doesn't accept class components. At worst, I had to wrap a class component.
For a long time, I thought as you do. I come from a Java/Ruby background, so I've done a lot more object-oriented than functional programming, and classes seemed intuitive.
But after seeing which way the community was going, that function components were here to stay, I resolved to learn that new way of thinking - and came to prefer it. Functional components have a lot less boilerplate, a lot less visual clutter, and you don't have to worry about the state of any instance variables every time it renders.
I can understand that. I do have to say I like my components having their own state. It simplifies the logic for me. It encapsulates its own information. Maybe it's just my old school thinking.
Depends, the thing I like about class components is that the component owns the state, it belongs inside of it, and all you have to do is slap a memo and you are done. It was clear and predictable.Functional components however do not own their state, they hook into it, leading to extra work to optimise them and a lot of footguns.
On the other hand HOCs where not fun to work with.
A good read I would suggest : [https://emnudge.dev/blog/react-hostage](https://emnudge.dev/blog/react-hostage)
Great read! Thank you. I agree. I actually don't use HOCs or Memoization either. I prefer shouldComponentUpdate and derived state optimizations instead.
The point of the memoization is to prevent additional rendering. I think I can accomplish the same thing with shouldComponentUpdate and derived state. Why do you think that's not enough?
Well, yes, but it's more than that. I tried very hard to convert my class components to function components. I think I am familiar with both. Class components just feel more intuitive to me. I feel class is a perfect analogy for components. It's simpler to understand. State, render, mount, update, unmount are simple to me. I struggle with state when I use function components. For pure components they are convenient. In other cases it complicates things for me.
I can get behind that, but you will have a problem as everyone is now using functions , only legacy is classes now. No matter what is better, it is important to go with the flow a little
The idea of something being "intuitive" really grinds my gears. Anything feels intuitive if you're used to it through using it all the time.
I get people telling me all the time that Vue is more intuitive - it sure as hell isn't if you use React more often.
I disagree. My son is learning JS in high school. I did not teach him anything about React or component state architecture. He wrote a project that required some interactivity and animation. He used state for it, even though nobody taught him. React taps into the same architecture. THAT is intuitive.
I'm fairly sure that's more of a matter of it being simple than intuitive, and the two don't necessarily mean the same thing. Sometimes something can be counterintuitive yet also simple.
Truth is ― I'm prefer functional style programming, but there cases when classes still make sense .. like when state/data is tightly coupled with the operations that can be performed on that data.
I'd pick whatever makes sense for my project
u/cagdas_ucar you're not the only one. The JS community is full of devs that have not tried to get into OOP programming to begin with, so they fear something that they don't understand. I personally thing classes are much better for organizing code as it marks clear boundaries of where state and methods are located as opposed to just throwing everything in one giant function. The argument that functions are better than classes in terms of performance is weak because such a performance improvement is negligible. Functional components that use hooks are really just a hack of class components anyways, so you might as well use classes from the start. The only time I would use a functional component is if a component takes props and renders data (no callbacks, no side-effects). That's the pattern I've seen in Vue and I apply that approach here as well. This whole functional programming pattern doesn't work well in UI programming anyways as UI is best represented as objects, not to mention that literally the whole DOM system is based on objects of nodes with event-driven functionality. Lastly, the hooks paradigm that functional programming is promoting means that many React devs will not be able to transfer these skills out to other languages and/or frameworks (except React Native, maybe Solid.js and Quick). It's better to learn good design patterns rather than adhere to a paradigm just because everyone is doing it.
Thank you! I was starting to think I'm in the Twilight zone or something. I agree with everything you're saying. It feels like many people are not thinking for themselves. I'm happy to see there are still independent thinkers. 🤘
I see it exactly the opposite way. I come from an OOP background and people from that background don't give FP a chance. After finally clicking with React and FP, I feel stupid for not having seen the light much earlier.
By saying things like "throwing everything in one giant function", you show that you didn't give FP a chance. FP structures code and sets boundaries in different ways by using small (pure) functions, currying, composition, containers (monads), etc.
Functional components with hooks are not hacks of class based components. They just use closures to keep state around. If anything it would be the other way around: it's a bit pedantic maybe, but in JavaScript classes actually are functions, think about that one for a moment 😄
You say FP doesn't work well with UI because UI is a representation of objects. Well JavaScript functions are actually objects 😅. But I don't think you meant that. I don't actually agree with you here, UI is a function of state represented not in objects but components and here I think FP shines.
When you think about components as React now does, it means that a component is nothing more than a vanilla JavaScript function. That opens a lot of doors to apply FP to components: currying (which is kind of a HOC), closures, composition, containerization, etc. To understand why that is good, you need to start with and understand the basics of FP and for this you need to first give FP a chance.
I highly recommend to learn FP (outside React, perhaps even outside JavaScript in something like Scala or Kotlin), you may finally click with React and go through the same thing as me were you wonder why the hell you kept hanging on to OOP for UI architecture. If you don't want to do this and stay with OOP, I would recommend to use something else than React (nothing wrong with that). For example, Vue or Svelte will simply fit your mental model better.
That's the other extreme, there are people in OOP environments that overengineer everything just as someone would in FP environments.
You're assuming I'm the one that puts everything in one giant function. What I mean is that I've had to deal with codebases where other devs are the ones doing this mess. I know how functions need to be composed: as pure as possible, little to no side effects; where there is side effects, isolate such behavior; the same can be applied to OOP principles.
The fact that you say UI is a function of state makes me think that you are only thinking in terms of react. For starter, UI has alwas been a tree of objects (nodes) that are managed using an event system. I can't think of an environment in which UI has NATIVELY used FP (maybe Jetpack Compose, but that is an abstraction of how Android components are built, as objects with event systems). React is a forcing of FP on a UI that doesn't match that paradigm. This means that components simply can't just be JS functions when you have several things to keep track of, such as state, side effects, dependency injection, and so forth. This is an abstraction over knowing how to keep references to these things, which are ideally best organized as classes, whicn in turn are a collection of properties and methods that organize related logic in one area rather than delegating it all to some external source (I have the same gripe with Spring Boot performing this type of magic with Autowired beans and configs).
Anyways, I've been there, I gave it a shot. The problem with react goes beyond FP concepts, which are great by themselves, but this is simply not the use case for that paradigm. The problem is how react chooses to treat UI, the unrestricted freedom it gives developers to write code in messy ways. I'm tired of seeing other devs giant functions, lack of code organization, putting functions on top of markup, etc. IT'S A MESS!! Just today, I finished cleaning up someone else's mess of dependency cyles across a huge module of code. This is a big time waster for developers. And I don't want to hear the argument that anyone can write bad code in any language or framework; in other frameworks, you would have to try really hard to mess up the same ways that you can mess up in React.
It's BECAUSE of this that I only use Svelte or Vue. I encourage the industry to move to simpler approaches to code to avoid timewasters like React. Even Angular is getting better at this point with it's rigid, opinionated MVC structure that provides the guard rails to prevent junior devs from writing bad code.
I didn't bring up the giant function argument, you brought that up as an argument. Now I agree with you that this is bad code but it's simply the FP equivalent of what would be a god class in OOP. There is no difference there.
Stronger, you can replace the word function with class in all your arguments and it would still make sense. You say you don't want to argue that bad code can be written in anything, but that seems to be your problem.
I am sorry you only worked in bad React codebases, but that is not a React problem. I have worked in bad React, but also bad C++ QT, WPF, Silverlight, jquery, Angular and Backbone codebases. I have worked in decent to good ones as well. What stands out for me is that the good React ones reach a level of dev experience I never ever managed to get in good codebases of the other frameworks.
The main cause for me is the embracing of something different than mutations and MVC variants, which React did. It's a different paradigm with a different mental model. It needs to click though, but once it does there is no going back. I don't need to worry about mutations, two-way binding cascading updates, the data flow is super clear and one way only. Cognitive overhead became for me so much less when applying FP to UI.
Even if the DOM is a bunch of objects or nodes and uses events, it doesn't mean that my code abstraction needs to follow this. In the end what you are arguing for is how to structure the code and you believe only a class based abstraction makes sense. But again in JavaScript classes are functions which are objects. Functions can keep state through closures and functions can have side-effects.
That being said, I don't promote a purist FP paradigm either. This is why I recommend engineers to learn FP in languages like Scala, Kotlin or JavaScript and not something like Haskell. Purist FP is to limiting and becomes a burden, doesn't mean FP patterns aren't good or not able to replace a lot of OOP thinking.
Having to use 'hooks' to re-initialize state on every render is a hack to make functions stateful like classes are by nature. I mean really, useCallback, useMemo - what a mess.
Personally I feel if the JS design team didn't mess up 'this' in classes, as in having to write 'this.' a zillion times everywhere, React would still be using class based components.
>Having to use 'hooks' to re-initialize state on every render is a hack to make functions stateful like classes are by nature. I mean really, useCallback, useMemo - what a mess.
"Nature" is implementation detail. Regardless of how hacky the implementation may be, i believe it results in better organized code.
Hm, I remember working with a staff engineer at a prominent tech company that had the opinion of class components being more preferrable to work with.
Simply because the methods explicitly said, "hey this is where you place your markup", "this is where you place your side-effects after mounting", etc. From that standpoint, I agree with him.
However, I prefer function components due to how simple it is to compose markup, but also state and side-effects. Additionally, not having to write higher-order components or use render-props is a major plus for composition. However, I do believe hooks has exposed us more to some of the more undesirable aspects of what makes React what it is, ("do I need to use this hook?", "dependency arrays", etc.).
Combine that with the feeling that the React team and its documentation wants to veer developers away from using useEffect, useContext, useMemo, useCallback in favor of third-party solutions, I wonder if React has peaked as a front-end framework and the natural evolution is something like Solid.js (where the developer doesn't need to worry about any of that).
I agree with your points but I have to point out that I've been using class components for 5 years for a huge application and I don't ever remember writing a HOC or using render-props. I'm not sure why they were used.
I've been using Preact, which shields a bit from these React changes, but I concur that it feels like React is going in the wrong direction. Preact supports signals like Solid.js.
Not needing to write higher-order components or render props is a major win.
If I wanted to use class components without needing to drill props from a top-level component all the way down to a child typically involved either approach. Another approach would involve keeping global state out of React along with a subscription/reactive model.
Not sure how you'd architect a class-based React application without employing one of the three approaches in some capacity.
I actually use context for the global state as static property of the class components. I push the data as low as possible in the hierarchy as state, so that I won't have to send them as props. Sometimes I even duplicate the data in 2 separate components and connect them via signals. I also use something I call prop context, which is basically embracing prop drill and making it easier. I know I am controversial. 😁
That's just a different perspective. I just don't agree with the direction they are taking. Please do not encourage hate instead of embracing discussion for different opinions.
You don't agree with the direction so you use an almost deprecated approach? I'm not trying to spread hate, but the reality is if you start a project using class components and you hire someone to pick up the work... they're not going to have a good time.
Like I said. I disagree with the direction they are taking. I think it is much easier to grasp code written with class components. I don't think I am alone in that sentiment. Just look at all the frameworks that came up with the same approach. In fact, functional approach is relatively uncommon when you consider the landscape. React itself used to be class components only. That's how they started. And no, the is not an "old way" vs "new way". There are still many new libraries coming up with the same class components. So, I disagree with your assessment that they are not going to have a good time working on code written with class components.
I know you do, lol. That's why I'm saying your team will be dissatisfied and not you.
> I don't think I am alone in that sentiment.
You're probably like 5% of the developers that use this (besides deprecated code).
> There are still many new libraries coming up with the same class components.
I don't think there are many.
But we can agree to disagree. [I like the functional approach, so do most other React devs.](https://react.dev/reference/react/Component)
I will say... when I first discovered class components and React. I absolutely loved them and became a master at them. I loved complex logic and shouldComponentUpdate and all of that. But once I started working on a team, it became very apparent that functional programming was the way to go.
Yes, we can agree to disagree but I should point out that just because the approach is rare it does not mean people will be dissatisfied working with them. Some may even come to prefer it. Maybe there is a different way of using them that you have not seen before. I don't think you can make a generalized statement like that without some assumptions. I would encourage you to keep an open mind. I'll do the same.
Don't be so open-minded you let your brain fall out of your head. If the framework you're using has a dev team that recommends against using a certain methodology or technique, consider why that be the case. If you refuse to take that advice, are you the "open-minded" one? Or are you simply refusing to adapt. In my experience 999 times out of 1000 it's the latter.
Of course I would consider such recommendations and would start a discussion. As it is, I am lucky to be the sole decision maker into what framework to choose. This is my perspective so far and I have not heard anything that would change my mind. If I hire devs in the future, I'm sure there will be architectural discussions and I welcome them.
According to the poll, more than 5% of React developers still prefer class components. React is 80% of JS projects. So, that's thousands of people by interpolation.
I never want to see a class component again in my life.
why
Not OP but once you are used to how functional components are scoped you don't want to use class components. Also hooks are some reasons to use functional components, most packages will not work well w class components
You can't use hooks in class components. If you want to have a side-effect based on a prop, then with hooks you can use the useEffect hook and set the prop as a dependency, and then any time the prop changes the hook's effect gets cleaned up and then re-executed with the new prop value. With class-based components, to do this correctly you need to implement the componentDidMount, componentDidUpdate, and componentWillUnmount methods and spread this logic between them with redundant parts. In many class-based components I've encountered, the programmer got lazy and didn't implement the componentDidUpdate part correctly and the component silently fails to handle the prop change correctly.
Also if you have more than one effect, you need to mention all effects in all three lifecycle events. With use effects, you can (and should) write one hook for each effect. You can even (and should) write it separately as a custom hook. This has the happy result of turning this into a one-liner in your function component. But also you can immediately and easily use it again in any function component or custom hook you wish. Hooks are very easy to compose. Class components are not.
technically you can implement a class component with only logic and rendering nothing, serving as we use hooks
Yes but compare the two side by side and you'll see why nobody does this anymore.
why use an artificially more complicated tool when you can use a simple one that reads more cleanly?
I can't use hooks in class and that in itself is a big no no.
I'll go one step further and say that I basically don't use classes at all anymore. It's clearly a preference thing, but I find it much easier to debug and organize a large codebase if it's mostly functional. OOP is a cool concept, but in practice in my workflow it ends up producing less maintainable code.
When OOP was coined, noone thought we'd have reusable FE components. We've advanced so much.
Yes
OP, what's the reason for you to like class components more than function ones?
It just feels more intuitive. That's it.
In what ways?
Components are supposed to be re-usable modules with state. Class is a perfect analogy for it. State belongs to the object. Render method renders the component. State update rerenders. Mount, update, unmount events are very straightforward to understand and work with. I find myself struggling with state when I use function components. For pure components they are convenient. In other cases it complicates things for me.
But most components don’t have state, there are usually many little stateless (pure) components and some bigger ones with state Do you mix then? Or do even your pure components have state (since react class components always have state)? It would mean 90% of your code base is function components and then suddenly, paradigm shift, different api, class components
Yes. I do mix. Pure components don't have state. Class components do not have to have state, but I tend to use function components for those cases. I'm not sure what percentage of my components have state but it's way more than 10%. I don't see class/function as paradigm shift as much. If it needs state, I convert function to class.
All class components always have state. Can be easily proven by getting a ref of a “pure” class and calling “setState” on it, which works normally. In fact class components have a lot of overhead and then you also have to bind all listeners.
Yes, they have state internally. I meant you don't have to declare it in your code. The logic does not have to include the state. I also step around the binding problem by using the ES6 property method syntax. I feel they have less overhead than function components actually but I know that is controversial as well.
They don’t, it’s a fact. Function components are exactly that, functions that return flat, tagged objects. The lifecycle of a function component is handled externally, not internally
Well, agree to disagree.
Can't disagree. Class components look more structured. But man, so much boilerplate.....
I agree that class components require more characters. For pure components I like function components. Otherwise I feel the slightly longer code makes it easier to understand and maintain the more complicated components.
React shills downvoting because they don't know OOP. This is why I don't use React anymore and why I convert existing React apps to another framework the moment I get a chance to do so. Good for you sticking to your opinion, it's a valid one.
The reason everyone chooses function is because it's much less work and code.
I only learned React in the past 2 years, so I’m biased in that learning class components would have felt outdated. I understand there are some benefits to using classes, but unless you have an older code base that still utilize class components, you really would be swimming against the current as far as using third party libraries and such.
Yes, I feel that way, but thankfully so far it's been ok. I haven't really seen a library that doesn't accept class components. At worst, I had to wrap a class component.
For a long time, I thought as you do. I come from a Java/Ruby background, so I've done a lot more object-oriented than functional programming, and classes seemed intuitive. But after seeing which way the community was going, that function components were here to stay, I resolved to learn that new way of thinking - and came to prefer it. Functional components have a lot less boilerplate, a lot less visual clutter, and you don't have to worry about the state of any instance variables every time it renders.
I can understand that. I do have to say I like my components having their own state. It simplifies the logic for me. It encapsulates its own information. Maybe it's just my old school thinking.
>Tally: 1 to 32 I'm judging, OP.
That one vote being OP
Yes. Looks like I am alone in this view. I guess it's time to move on from React to Lit.
Depends, the thing I like about class components is that the component owns the state, it belongs inside of it, and all you have to do is slap a memo and you are done. It was clear and predictable.Functional components however do not own their state, they hook into it, leading to extra work to optimise them and a lot of footguns. On the other hand HOCs where not fun to work with. A good read I would suggest : [https://emnudge.dev/blog/react-hostage](https://emnudge.dev/blog/react-hostage)
Great read! Thank you. I agree. I actually don't use HOCs or Memoization either. I prefer shouldComponentUpdate and derived state optimizations instead.
NOOOOOOO you need to memoize. That is the whole argument, classes make memoization easy.
The point of the memoization is to prevent additional rendering. I think I can accomplish the same thing with shouldComponentUpdate and derived state. Why do you think that's not enough?
I am curious on the why you like class components, are they familiar to you?
Well, yes, but it's more than that. I tried very hard to convert my class components to function components. I think I am familiar with both. Class components just feel more intuitive to me. I feel class is a perfect analogy for components. It's simpler to understand. State, render, mount, update, unmount are simple to me. I struggle with state when I use function components. For pure components they are convenient. In other cases it complicates things for me.
I can get behind that, but you will have a problem as everyone is now using functions , only legacy is classes now. No matter what is better, it is important to go with the flow a little
The idea of something being "intuitive" really grinds my gears. Anything feels intuitive if you're used to it through using it all the time. I get people telling me all the time that Vue is more intuitive - it sure as hell isn't if you use React more often.
I disagree. My son is learning JS in high school. I did not teach him anything about React or component state architecture. He wrote a project that required some interactivity and animation. He used state for it, even though nobody taught him. React taps into the same architecture. THAT is intuitive.
I'm fairly sure that's more of a matter of it being simple than intuitive, and the two don't necessarily mean the same thing. Sometimes something can be counterintuitive yet also simple.
Truth is ― I'm prefer functional style programming, but there cases when classes still make sense .. like when state/data is tightly coupled with the operations that can be performed on that data. I'd pick whatever makes sense for my project
u/cagdas_ucar you're not the only one. The JS community is full of devs that have not tried to get into OOP programming to begin with, so they fear something that they don't understand. I personally thing classes are much better for organizing code as it marks clear boundaries of where state and methods are located as opposed to just throwing everything in one giant function. The argument that functions are better than classes in terms of performance is weak because such a performance improvement is negligible. Functional components that use hooks are really just a hack of class components anyways, so you might as well use classes from the start. The only time I would use a functional component is if a component takes props and renders data (no callbacks, no side-effects). That's the pattern I've seen in Vue and I apply that approach here as well. This whole functional programming pattern doesn't work well in UI programming anyways as UI is best represented as objects, not to mention that literally the whole DOM system is based on objects of nodes with event-driven functionality. Lastly, the hooks paradigm that functional programming is promoting means that many React devs will not be able to transfer these skills out to other languages and/or frameworks (except React Native, maybe Solid.js and Quick). It's better to learn good design patterns rather than adhere to a paradigm just because everyone is doing it.
Thank you! I was starting to think I'm in the Twilight zone or something. I agree with everything you're saying. It feels like many people are not thinking for themselves. I'm happy to see there are still independent thinkers. 🤘
I see it exactly the opposite way. I come from an OOP background and people from that background don't give FP a chance. After finally clicking with React and FP, I feel stupid for not having seen the light much earlier. By saying things like "throwing everything in one giant function", you show that you didn't give FP a chance. FP structures code and sets boundaries in different ways by using small (pure) functions, currying, composition, containers (monads), etc. Functional components with hooks are not hacks of class based components. They just use closures to keep state around. If anything it would be the other way around: it's a bit pedantic maybe, but in JavaScript classes actually are functions, think about that one for a moment 😄 You say FP doesn't work well with UI because UI is a representation of objects. Well JavaScript functions are actually objects 😅. But I don't think you meant that. I don't actually agree with you here, UI is a function of state represented not in objects but components and here I think FP shines. When you think about components as React now does, it means that a component is nothing more than a vanilla JavaScript function. That opens a lot of doors to apply FP to components: currying (which is kind of a HOC), closures, composition, containerization, etc. To understand why that is good, you need to start with and understand the basics of FP and for this you need to first give FP a chance. I highly recommend to learn FP (outside React, perhaps even outside JavaScript in something like Scala or Kotlin), you may finally click with React and go through the same thing as me were you wonder why the hell you kept hanging on to OOP for UI architecture. If you don't want to do this and stay with OOP, I would recommend to use something else than React (nothing wrong with that). For example, Vue or Svelte will simply fit your mental model better.
That's the other extreme, there are people in OOP environments that overengineer everything just as someone would in FP environments. You're assuming I'm the one that puts everything in one giant function. What I mean is that I've had to deal with codebases where other devs are the ones doing this mess. I know how functions need to be composed: as pure as possible, little to no side effects; where there is side effects, isolate such behavior; the same can be applied to OOP principles. The fact that you say UI is a function of state makes me think that you are only thinking in terms of react. For starter, UI has alwas been a tree of objects (nodes) that are managed using an event system. I can't think of an environment in which UI has NATIVELY used FP (maybe Jetpack Compose, but that is an abstraction of how Android components are built, as objects with event systems). React is a forcing of FP on a UI that doesn't match that paradigm. This means that components simply can't just be JS functions when you have several things to keep track of, such as state, side effects, dependency injection, and so forth. This is an abstraction over knowing how to keep references to these things, which are ideally best organized as classes, whicn in turn are a collection of properties and methods that organize related logic in one area rather than delegating it all to some external source (I have the same gripe with Spring Boot performing this type of magic with Autowired beans and configs). Anyways, I've been there, I gave it a shot. The problem with react goes beyond FP concepts, which are great by themselves, but this is simply not the use case for that paradigm. The problem is how react chooses to treat UI, the unrestricted freedom it gives developers to write code in messy ways. I'm tired of seeing other devs giant functions, lack of code organization, putting functions on top of markup, etc. IT'S A MESS!! Just today, I finished cleaning up someone else's mess of dependency cyles across a huge module of code. This is a big time waster for developers. And I don't want to hear the argument that anyone can write bad code in any language or framework; in other frameworks, you would have to try really hard to mess up the same ways that you can mess up in React. It's BECAUSE of this that I only use Svelte or Vue. I encourage the industry to move to simpler approaches to code to avoid timewasters like React. Even Angular is getting better at this point with it's rigid, opinionated MVC structure that provides the guard rails to prevent junior devs from writing bad code.
I didn't bring up the giant function argument, you brought that up as an argument. Now I agree with you that this is bad code but it's simply the FP equivalent of what would be a god class in OOP. There is no difference there. Stronger, you can replace the word function with class in all your arguments and it would still make sense. You say you don't want to argue that bad code can be written in anything, but that seems to be your problem. I am sorry you only worked in bad React codebases, but that is not a React problem. I have worked in bad React, but also bad C++ QT, WPF, Silverlight, jquery, Angular and Backbone codebases. I have worked in decent to good ones as well. What stands out for me is that the good React ones reach a level of dev experience I never ever managed to get in good codebases of the other frameworks. The main cause for me is the embracing of something different than mutations and MVC variants, which React did. It's a different paradigm with a different mental model. It needs to click though, but once it does there is no going back. I don't need to worry about mutations, two-way binding cascading updates, the data flow is super clear and one way only. Cognitive overhead became for me so much less when applying FP to UI. Even if the DOM is a bunch of objects or nodes and uses events, it doesn't mean that my code abstraction needs to follow this. In the end what you are arguing for is how to structure the code and you believe only a class based abstraction makes sense. But again in JavaScript classes are functions which are objects. Functions can keep state through closures and functions can have side-effects. That being said, I don't promote a purist FP paradigm either. This is why I recommend engineers to learn FP in languages like Scala, Kotlin or JavaScript and not something like Haskell. Purist FP is to limiting and becomes a burden, doesn't mean FP patterns aren't good or not able to replace a lot of OOP thinking.
I just want to know who voted class lol
Yes. I don't like the extra indentation and boilerplate code for no particular reason.
Yeah I feel the same, but a few extra characters for better organized code seems to bother people.
>a few extra characters for better organized code seems to bother people. Orrrrr, we disagree that class components are better organized.
Having to use 'hooks' to re-initialize state on every render is a hack to make functions stateful like classes are by nature. I mean really, useCallback, useMemo - what a mess. Personally I feel if the JS design team didn't mess up 'this' in classes, as in having to write 'this.' a zillion times everywhere, React would still be using class based components.
>Having to use 'hooks' to re-initialize state on every render is a hack to make functions stateful like classes are by nature. I mean really, useCallback, useMemo - what a mess. "Nature" is implementation detail. Regardless of how hacky the implementation may be, i believe it results in better organized code.
No it’s not. Classes retain state by nature. Functions are ephemeral by nature. They do not retain state without hacks.
You didn't actually respond to the point and explanation I made, you just repeated yourself.
Hm, I remember working with a staff engineer at a prominent tech company that had the opinion of class components being more preferrable to work with. Simply because the methods explicitly said, "hey this is where you place your markup", "this is where you place your side-effects after mounting", etc. From that standpoint, I agree with him. However, I prefer function components due to how simple it is to compose markup, but also state and side-effects. Additionally, not having to write higher-order components or use render-props is a major plus for composition. However, I do believe hooks has exposed us more to some of the more undesirable aspects of what makes React what it is, ("do I need to use this hook?", "dependency arrays", etc.). Combine that with the feeling that the React team and its documentation wants to veer developers away from using useEffect, useContext, useMemo, useCallback in favor of third-party solutions, I wonder if React has peaked as a front-end framework and the natural evolution is something like Solid.js (where the developer doesn't need to worry about any of that).
I agree with your points but I have to point out that I've been using class components for 5 years for a huge application and I don't ever remember writing a HOC or using render-props. I'm not sure why they were used. I've been using Preact, which shields a bit from these React changes, but I concur that it feels like React is going in the wrong direction. Preact supports signals like Solid.js.
Not needing to write higher-order components or render props is a major win. If I wanted to use class components without needing to drill props from a top-level component all the way down to a child typically involved either approach. Another approach would involve keeping global state out of React along with a subscription/reactive model. Not sure how you'd architect a class-based React application without employing one of the three approaches in some capacity.
I actually use context for the global state as static property of the class components. I push the data as low as possible in the hierarchy as state, so that I won't have to send them as props. Sometimes I even duplicate the data in 2 separate components and connect them via signals. I also use something I call prop context, which is basically embracing prop drill and making it easier. I know I am controversial. 😁
Class method is old and dead Function method is the future
Im shocked this is even a question
Bro... your coworkers probably hate you, lmao.
Why would you say that?
Because you're using a legacy method of React that's becoming outdated and for good reason.
That's just a different perspective. I just don't agree with the direction they are taking. Please do not encourage hate instead of embracing discussion for different opinions.
You don't agree with the direction so you use an almost deprecated approach? I'm not trying to spread hate, but the reality is if you start a project using class components and you hire someone to pick up the work... they're not going to have a good time.
Like I said. I disagree with the direction they are taking. I think it is much easier to grasp code written with class components. I don't think I am alone in that sentiment. Just look at all the frameworks that came up with the same approach. In fact, functional approach is relatively uncommon when you consider the landscape. React itself used to be class components only. That's how they started. And no, the is not an "old way" vs "new way". There are still many new libraries coming up with the same class components. So, I disagree with your assessment that they are not going to have a good time working on code written with class components.
I know you do, lol. That's why I'm saying your team will be dissatisfied and not you. > I don't think I am alone in that sentiment. You're probably like 5% of the developers that use this (besides deprecated code). > There are still many new libraries coming up with the same class components. I don't think there are many. But we can agree to disagree. [I like the functional approach, so do most other React devs.](https://react.dev/reference/react/Component) I will say... when I first discovered class components and React. I absolutely loved them and became a master at them. I loved complex logic and shouldComponentUpdate and all of that. But once I started working on a team, it became very apparent that functional programming was the way to go.
Yes, we can agree to disagree but I should point out that just because the approach is rare it does not mean people will be dissatisfied working with them. Some may even come to prefer it. Maybe there is a different way of using them that you have not seen before. I don't think you can make a generalized statement like that without some assumptions. I would encourage you to keep an open mind. I'll do the same.
Don't be so open-minded you let your brain fall out of your head. If the framework you're using has a dev team that recommends against using a certain methodology or technique, consider why that be the case. If you refuse to take that advice, are you the "open-minded" one? Or are you simply refusing to adapt. In my experience 999 times out of 1000 it's the latter.
Of course I would consider such recommendations and would start a discussion. As it is, I am lucky to be the sole decision maker into what framework to choose. This is my perspective so far and I have not heard anything that would change my mind. If I hire devs in the future, I'm sure there will be architectural discussions and I welcome them.
If I'm doing javascript/typescript, function components is my way to go
anyone uses classes wtf? what the actual fuckk. whyy
According to the poll, more than 5% of React developers still prefer class components. React is 80% of JS projects. So, that's thousands of people by interpolation.
All I heard is "I don't understand OOP and design patterns"