I like this line of posts that dig deep into concepts and semantics. I agree on many of the points.
My mental model for the render function is that it renders the component to the virtual Dom every time it is called. The reconciliation between the current and previous virtual Doms happen at the end of the cycle and may or may not result in updates to the real Dom
There is also the usual tension between imperative and declarative here. 'render' sounds imperative but it returns jsx which is declarative
You bring up a good point here. As you know from my prior posts, I genuinely like the declarative syntax. But I feel strongly that there's a logical place for imperative commands - and it can get confusing when you try to shuffle the two together.
Maciej Sikora commented here that he thinks the naming of the render() function makes sense. I don't personally agree. But it hadn't occurred to me that, maybe the reason I feel differently, is because I still think, often, in imperative paradigms.
To me, every function should always be named after an action. And "rendering" is an action. But when you call render() and no changes are made to the DOM, IMHO, the function didn't do what it claimed to do.
To be clear, this is semantic. And I obviously don't expect anyone on the React team to change the naming conventions. In this particular post, I only write about it because, IMHO, that ambiguity leads to outright misunderstanding on the part of a lotta devs.
As I showed in my "Static Components" demo, there are many React devs who would swear that example leads to "unnecessary rerenders". But... it doesn't.
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 like this line of posts that dig deep into concepts and semantics. I agree on many of the points.
My mental model for the render function is that it renders the component to the virtual Dom every time it is called. The reconciliation between the current and previous virtual Doms happen at the end of the cycle and may or may not result in updates to the real Dom
There is also the usual tension between imperative and declarative here. 'render' sounds imperative but it returns jsx which is declarative
You bring up a good point here. As you know from my prior posts, I genuinely like the declarative syntax. But I feel strongly that there's a logical place for imperative commands - and it can get confusing when you try to shuffle the two together.
Maciej Sikora commented here that he thinks the naming of the
render()function makes sense. I don't personally agree. But it hadn't occurred to me that, maybe the reason I feel differently, is because I still think, often, in imperative paradigms.To me, every function should always be named after an action. And "rendering" is an action. But when you call
render()and no changes are made to the DOM, IMHO, the function didn't do what it claimed to do.To be clear, this is semantic. And I obviously don't expect anyone on the React team to change the naming conventions. In this particular post, I only write about it because, IMHO, that ambiguity leads to outright misunderstanding on the part of a lotta devs.
As I showed in my "Static Components" demo, there are many React devs who would swear that example leads to "unnecessary rerenders". But... it doesn't.