DEV Community

Discussion on: React's Odd Obsession With Declarative Syntax

cbovis profile image
Craig Bovis

For the sake of the illustration, we'll also assume that the username is known at the point that the component is mounted, and that the username is immutable.

I've seen this assumption fail time and time again in projects I've worked on. In my opinion it's always worth putting the effort into assuming a component's props can and will change. In this case that would mean deriving from React.PureComponent or using React.memo to avoid the unnecessary re-renders. By ensuring your rendered UI always reflects current props/state the component will be much better at standing the test of time.

bytebodger profile image
Adam Nathaniel Davis Author

You're absolutely correct, but the question of when/if the props change kinda misses my point. That's on me. I'm sure I didn't do a strong-enough job of describing the central concept I was trying to illustrate.

I only created those arbitrary rules for the sake of illustration. What I was trying to say is that: There are times when you want AlgorithmX to only run one time. Or other times when you only want AlgorithmX to run in response to a very specific event. But sooooo much of the React ecosphere that I run into takes the general approach of, "Just drop this component into the render()/return() and it'll all be fine. But it's not fine. That approach hands over the control of your logic to the virtual-DOM-update process.

That's why, further down, I gave a more concrete use-case with regard to API/GraphQL/Apollo calls. With regard to API calls, I never want to leave their execution in the hands of React's re-rendering cycle. I know when I want an API call to run - and I only want it to run at that time.

In the other comments, Isaac Hagoel summarized it better than I did. It's a matter of time. A declarative syntax is like programming without regard to when a given call takes place. In many scenarios, that works wonderfully and can make your code much cleaner. But for some functions/algorithms/whatever, it's absolutely the wrong approach.

bytebodger profile image
Adam Nathaniel Davis Author • Edited on

Your response does raise an interesting thought in my mind about memoization and its use in React. Memoization is powerful and is almost certainly underused. But it's possible that some React devs see this as a (rather lazy) way to chunk everything into the render() process, relying on the memoization (which is another way of saying "cache") to properly sort out when to re-run the algorithm.

And that's all fine-and-good. But if I can choose between

A. Craft a single, imperative function that I know will only run once.
B. Memoize the function, throw it into the render process, and let the React engine figure out on every subsequent re-render whether that function needs to be called again.

I'll almost always choose A.