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.
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!