I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
You are correctly addressing the issue. But I am reading your x article and as at beginning I thought you are just pragmatist, now I think you have real problem with functions as components.
As I have nothing to classes, you can use them still and there are cases where hooks can be more confusing, whereas saying that functions as components are for FP fanboys is going to far.
BTW FP fanboys do really more badass things than writing functions without even having any impact on how these functions are finally composed in the runtime.
React team nicely have spotted the issue with lifecycle, lifecycle is not any new idea, every UI framework has some kind of lifecycle. Problem was that lifecycle was not clearly indicating when - what should be done. Hooks address this issue by targeting what dev want to do, instead when he wants to do it. So instead of when I should call effect, I just useEffect and React should do it's job about when it will be executed.
And yes not everything is great in hooks, as some things looks more implicit and tricky
Going back to the main subject - you are saying that naming of render function is wrong. And I agree it creates a confusion in terms of what renders means. Developers are rightly confusing this name with real render, and I dont blame them for that as I was confusing it also. So we are on the same page here, but in contrary to your opinion I see function as component as the solution for that. We don't see this confusing name, we just return the nodes structure. When and if this will have impact on DOM is in concern of React. And this is exactly how it should be. We define what we use and we return what we want to see, other things are covered by abstraction.
Changing name render into reconcile would be even more confusing as reconsilation is implementation detail, diffing is implementation detail. We just return what we want to render in the page, so that why they have chosen this name, as this is what you want to render, but it doesn't mean it will be.
But as I said before I agree with you that confusion between real DOM updated and calling function which returns react nodes structure is confusing. So thank you for the article.
Well, I used "fanboys" once in this article - and... that's the particular word you choose to focus on?? Umm... OK. Seems like you get a little sensitive over that word. It's nothing that bothers me.
As for your assessment of useEffect(), the idea that "I just useEffect and React should do it's job about when it will be executed" is... interesting. If you think that useEffect() replaces all of the lifecycle methods in class components, then you apparently weren't using all of the lifecycle methods in class components.
But I'm glad that useEffect() is so useful for you.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
My point was - in almost every article you make you cannot handle yourself to make a point against functions in React. This article is good, but the part related to functional component has nothing to the point you are making, it's like additional throwing into the article some words against that. No sense in my opinion, you could be saying just that the confusion about the wording of rendering has not disappeared with functions. It's true.
Also in your response you needed to say that probably I didn't use lifecycle if I think hooks can replace it. It's interesting point that React team thinks you can make software by hooks only. How then hooks cannot replace lifecycle?
I am pragmatist myself. I don't like to fall into some technology as the best. But I also don't like constant pointing in something even though it has nothing to the problem.
I see you prefer classes, ok. But there are least the same amount of points against classes in React as for hooks. I prefer hooks that's it. Does it makes me a hook fanboy? If so you are class components fanboy, but I believe you don't feel as one.
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.
You are correctly addressing the issue. But I am reading your x article and as at beginning I thought you are just pragmatist, now I think you have real problem with functions as components.
As I have nothing to classes, you can use them still and there are cases where hooks can be more confusing, whereas saying that functions as components are for FP fanboys is going to far.
BTW FP fanboys do really more badass things than writing functions without even having any impact on how these functions are finally composed in the runtime.
React team nicely have spotted the issue with lifecycle, lifecycle is not any new idea, every UI framework has some kind of lifecycle. Problem was that lifecycle was not clearly indicating when - what should be done. Hooks address this issue by targeting what dev want to do, instead when he wants to do it. So instead of when I should call effect, I just useEffect and React should do it's job about when it will be executed.
And yes not everything is great in hooks, as some things looks more implicit and tricky
Going back to the main subject - you are saying that naming of render function is wrong. And I agree it creates a confusion in terms of what renders means. Developers are rightly confusing this name with real render, and I dont blame them for that as I was confusing it also. So we are on the same page here, but in contrary to your opinion I see function as component as the solution for that. We don't see this confusing name, we just return the nodes structure. When and if this will have impact on DOM is in concern of React. And this is exactly how it should be. We define what we use and we return what we want to see, other things are covered by abstraction.
Changing name render into reconcile would be even more confusing as reconsilation is implementation detail, diffing is implementation detail. We just return what we want to render in the page, so that why they have chosen this name, as this is what you want to render, but it doesn't mean it will be.
But as I said before I agree with you that confusion between real DOM updated and calling function which returns react nodes structure is confusing. So thank you for the article.
Well, I used "fanboys" once in this article - and... that's the particular word you choose to focus on?? Umm... OK. Seems like you get a little sensitive over that word. It's nothing that bothers me.
As for your assessment of
useEffect(), the idea that "I just useEffect and React should do it's job about when it will be executed" is... interesting. If you think thatuseEffect()replaces all of the lifecycle methods in class components, then you apparently weren't using all of the lifecycle methods in class components.But I'm glad that
useEffect()is so useful for you.I appreciate the feedback!
My point was - in almost every article you make you cannot handle yourself to make a point against functions in React. This article is good, but the part related to functional component has nothing to the point you are making, it's like additional throwing into the article some words against that. No sense in my opinion, you could be saying just that the confusion about the wording of rendering has not disappeared with functions. It's true.
Also in your response you needed to say that probably I didn't use lifecycle if I think hooks can replace it. It's interesting point that React team thinks you can make software by hooks only. How then hooks cannot replace lifecycle?
I am pragmatist myself. I don't like to fall into some technology as the best. But I also don't like constant pointing in something even though it has nothing to the problem.
I see you prefer classes, ok. But there are least the same amount of points against classes in React as for hooks. I prefer hooks that's it. Does it makes me a hook fanboy? If so you are class components fanboy, but I believe you don't feel as one.