I don't think es6 classes are bad, it's just syntaxic sugar over js prototypes. Having a mental model based on c#/java OO model in JS seems error prone to me. If you want to do serious sh*t with OOP you should learn and understand prototypes and not reproduce c# code. "this" in JS has a totally different meaning.
Having said that, IMO, except if you're stuck with Angular (in 2020 really ?), you should definitively get rid if OO in JS , especially with "this", and with inner state in classes, unless you fully understand what you do.
And if you use classes only to organize your code, maybe just use es6 modules with plain old functions !
I'm pretty neutral on Angular - but there's a lot of Angular out there. So it's not as though writing Angular code in 2020 is somehow... antiquated. But if I have my choice, I'll use React over Angular every single time.
With regard to this, like most JS devs, I used to have my share of headaches with it. But since the introduction of const and let, I can't honestly remember the last time that I ran into any kinda problem with this. In a class-based component, this simply refers to this class. But I understand that many people now are very leery of any use of this.
And with regard to "inner state in classes", if you're doing React, you can now use Hooks. But that just allows you to create a function - with inner state. So I'm still a little baffled sometimes by the people who rail against state in class-based components, but have no problem with useState() in functional components.
But none of these points are meant as any kinda "argument" to your comments. I hear what you're saying, and for the most part, I don't really disagree at all.
In my company (french insurance), we have a legacy codebase in angularjs (with es6 classes) and a New one in react (mainly with fonctional components). I can guarantee "this" led to many issues, especially with junior devs, and especially when bind () is used !
About inner state : Indeed, inner state aren't a problem in React (class based or functional components) because of React oneway dataflow. But when you write class based services, inner state Can be shared and you don't control where the mutations come from. With aggregates of pure functions, you can avoid those bad interactions.
I can guarantee "this" led to many issues, especially with junior devs, and especially when bind () is used !
I've put (I think somewhere else in this same post's comments), that, to me at least, I've always felt like the .bind() issue is a bit of a red herring - because, with class-based components, you never actually have to bind - ever. But I understand that there's a lotta legacy code using .bind() and, when I first started doing React, I was following the "official" examples and using it myself - but I hated it.
Of course, I realize that just because you don't have to use it, doesn't mean that people aren't still using it. And I realize that this causes confusion. It did for me, at first, until I learned to forgo it entirely.
But when you write class based services, inner state Can be shared and you don't control where the mutations come from. With aggregates of pure functions, you can avoid those bad interactions.
Well... inner state can be shared in functional components as well. I get your point. Entirely. But this issue isn't (IMHO) a class-vs-function issue. It's a "how do we manage shared state" issue.
As for pure functions, again, I basically agree with you. I will only add that, amongst some of my friends who are hardcore FP acolytes, they talk about "pure state" the way some people talk about "enlightenment". And I get it. The more pure functions you can write - the easier it will probably be to avoid nasty bugs down the line.
But the whole "pure functions" discussion is, to some extent, theoretical. Because any app that really does anything of merit will, at some point, have to manage state. If, for example, the user has logged in, you obviously must be able to "remember" the simple fact that the user has logged in. And you have to maintain that data... somewhere.
But again, none of these "points" are meant, in any way, as "arguments". I hear what you're saying. And I pretty much agree. I'm only writing functional components now. And I'm trying, whenever possible, to factor my code into pure functions wherever the logic allows.
Agreed ! you can do great things with classes, limit bad or risky practices, but unfortunately when you share your codebase with 1, 2, 10 or 100 people, you never know which level of care each of one will bring.
I agree, ultimately you have to put a state somewhere and fp purists are often very blurry about where to put it. Flux then Redux answered that in a interesting but verbose way. hooks allow you to use plenty pieces of state, it's so convenient and I love use them but still cannot convince myself it's the ultimate best practice!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think es6 classes are bad, it's just syntaxic sugar over js prototypes. Having a mental model based on c#/java OO model in JS seems error prone to me. If you want to do serious sh*t with OOP you should learn and understand prototypes and not reproduce c# code. "this" in JS has a totally different meaning.
Having said that, IMO, except if you're stuck with Angular (in 2020 really ?), you should definitively get rid if OO in JS , especially with "this", and with inner state in classes, unless you fully understand what you do.
And if you use classes only to organize your code, maybe just use es6 modules with plain old functions !
A few thoughts:
I'm pretty neutral on Angular - but there's a lot of Angular out there. So it's not as though writing Angular code in 2020 is somehow... antiquated. But if I have my choice, I'll use React over Angular every single time.
With regard to
this, like most JS devs, I used to have my share of headaches with it. But since the introduction ofconstandlet, I can't honestly remember the last time that I ran into any kinda problem withthis. In a class-based component,thissimply refers to this class. But I understand that many people now are very leery of any use ofthis.And with regard to "inner state in classes", if you're doing React, you can now use Hooks. But that just allows you to create a function - with inner state. So I'm still a little baffled sometimes by the people who rail against state in class-based components, but have no problem with
useState()in functional components.But none of these points are meant as any kinda "argument" to your comments. I hear what you're saying, and for the most part, I don't really disagree at all.
Thank you for the comments!
In my company (french insurance), we have a legacy codebase in angularjs (with es6 classes) and a New one in react (mainly with fonctional components). I can guarantee "this" led to many issues, especially with junior devs, and especially when bind () is used !
About inner state : Indeed, inner state aren't a problem in React (class based or functional components) because of React oneway dataflow. But when you write class based services, inner state Can be shared and you don't control where the mutations come from. With aggregates of pure functions, you can avoid those bad interactions.
I've put (I think somewhere else in this same post's comments), that, to me at least, I've always felt like the
.bind()issue is a bit of a red herring - because, with class-based components, you never actually have to bind - ever. But I understand that there's a lotta legacy code using.bind()and, when I first started doing React, I was following the "official" examples and using it myself - but I hated it.Of course, I realize that just because you don't have to use it, doesn't mean that people aren't still using it. And I realize that this causes confusion. It did for me, at first, until I learned to forgo it entirely.
Well... inner state can be shared in functional components as well. I get your point. Entirely. But this issue isn't (IMHO) a class-vs-function issue. It's a "how do we manage shared state" issue.
As for pure functions, again, I basically agree with you. I will only add that, amongst some of my friends who are hardcore FP acolytes, they talk about "pure state" the way some people talk about "enlightenment". And I get it. The more pure functions you can write - the easier it will probably be to avoid nasty bugs down the line.
But the whole "pure functions" discussion is, to some extent, theoretical. Because any app that really does anything of merit will, at some point, have to manage state. If, for example, the user has logged in, you obviously must be able to "remember" the simple fact that the user has logged in. And you have to maintain that data... somewhere.
But again, none of these "points" are meant, in any way, as "arguments". I hear what you're saying. And I pretty much agree. I'm only writing functional components now. And I'm trying, whenever possible, to factor my code into pure functions wherever the logic allows.
Agreed ! you can do great things with classes, limit bad or risky practices, but unfortunately when you share your codebase with 1, 2, 10 or 100 people, you never know which level of care each of one will bring.
I agree, ultimately you have to put a state somewhere and fp purists are often very blurry about where to put it. Flux then Redux answered that in a interesting but verbose way. hooks allow you to use plenty pieces of state, it's so convenient and I love use them but still cannot convince myself it's the ultimate best practice!