I will add here that, even in the documentation for class-based components, there's a general assumption on the part of the React team that constructor functionality is limited to initializing state. In my personal experience, I know that, on numerous occasions, I've found it prudent to handle other bits of logic in this part of the component life-cycle. Specifically, there are times when I want to prepare variables that will be used in the component, but I don't want the updating of those variables to be tied to state. In other words, there are sometimes some variables that I want to live outside of the rendering process. When I need to do any pre-processing on said variables, the constructor is an ideal place to do so.
I'm always willing to learn different ways and adapt, but i used to use a react constructor to pre-prep a lot of data, even for static websites. For instance i might translate a linear array into a 2d one better suited for defining a layout. Things like that. I guess i could do it another way but they all just seem like added complexity.
The easiest analogy is componentWillMount. Anything that anyone previously wanted to stuff in componentWillMount is a prime candidate to be put in the constructor. But don't take my word for it. This is directly from the React docs:
UNSAFE_componentWillMount() is invoked just before mounting occurs. It is called before render(), therefore calling setState() synchronously in this method will not trigger an extra rendering. Generally, we recommend using the constructor() instead for initializing state.
So if you were using old-skool React, you might've had a handful of components that used componentWillMount(). Then, that was deemed to be unsafe, and the maintainers themselves said, "Now you should move it to the constructor(). But with function-based components, there is no constructor.
Again, as I stated in the post, I'm not claiming that this is functionality that you'd need on all components. You won't even need it on most components. But the fact that we previously had componentWillMount() and constructor() signals that there are valid use-cases for it.
Unfortunately using a constructor seems to be the only way to go if you are using Redux and you don't want to blink a "no data" message or stale data before a fetch action is dispatched in useEffect. Having worked with other frameworks, I am simply amazed by having to do this ugliness in React...
Interesting/related note: This article has quietly gathered more views than anything else I've written. Unlike most of my articles, that have a certain "splash" for a few days - and then are rarely read again - this article continues to get a steady stream of traffic.
What's the point?? Well, it would seem that there are a lot of other people out there who are switching to Hooks, then saying, "Wait a minute. How do I create a constructor with Hook??", then they start googling and end up on my article. (And there seems to be very few other articles out there on the same topic.)
So while it may indeed be "ugliness", I surmise that there are many others who are confused/annoyed by the (FALSE) idea that you can simply use useEffect() to replace all of the previous lifecycle methods, and there's no logical reason to use the constructor functionality that we had in class-based components.
Thank you for writing this article! I thought I was missing something by always having to skip renders with a flag which is set only after a fetch is started in useEffect or trying to do fetch calls in something like your constructor. Seems that React devs have missed the point that sometimes you need to have a cause before you can handle the effect...
Having spent years working with the lifecycle methods that are available in class-based components, I'll be the first to tell you that they can, at times, cause major headaches. But the Hooks team seems to have decided that the way to cure the headache is to cut off the head.
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.
Could you give an example where a constructor would be useful?
I will add here that, even in the documentation for class-based components, there's a general assumption on the part of the React team that constructor functionality is limited to initializing state. In my personal experience, I know that, on numerous occasions, I've found it prudent to handle other bits of logic in this part of the component life-cycle. Specifically, there are times when I want to prepare variables that will be used in the component, but I don't want the updating of those variables to be tied to state. In other words, there are sometimes some variables that I want to live outside of the rendering process. When I need to do any pre-processing on said variables, the constructor is an ideal place to do so.
I'm always willing to learn different ways and adapt, but i used to use a react constructor to pre-prep a lot of data, even for static websites. For instance i might translate a linear array into a 2d one better suited for defining a layout. Things like that. I guess i could do it another way but they all just seem like added complexity.
The easiest analogy is
componentWillMount. Anything that anyone previously wanted to stuff incomponentWillMountis a prime candidate to be put in the constructor. But don't take my word for it. This is directly from the React docs:So if you were using old-skool React, you might've had a handful of components that used
componentWillMount(). Then, that was deemed to be unsafe, and the maintainers themselves said, "Now you should move it to theconstructor(). But with function-based components, there is no constructor.Again, as I stated in the post, I'm not claiming that this is functionality that you'd need on all components. You won't even need it on most components. But the fact that we previously had
componentWillMount()andconstructor()signals that there are valid use-cases for it.Unfortunately using a constructor seems to be the only way to go if you are using Redux and you don't want to blink a "no data" message or stale data before a fetch action is dispatched in useEffect. Having worked with other frameworks, I am simply amazed by having to do this ugliness in React...
Interesting/related note: This article has quietly gathered more views than anything else I've written. Unlike most of my articles, that have a certain "splash" for a few days - and then are rarely read again - this article continues to get a steady stream of traffic.
What's the point?? Well, it would seem that there are a lot of other people out there who are switching to Hooks, then saying, "Wait a minute. How do I create a constructor with Hook??", then they start googling and end up on my article. (And there seems to be very few other articles out there on the same topic.)
So while it may indeed be "ugliness", I surmise that there are many others who are confused/annoyed by the (
FALSE) idea that you can simply useuseEffect()to replace all of the previous lifecycle methods, and there's no logical reason to use the constructor functionality that we had in class-based components.Thank you for writing this article! I thought I was missing something by always having to skip renders with a flag which is set only after a fetch is started in useEffect or trying to do fetch calls in something like your constructor. Seems that React devs have missed the point that sometimes you need to have a cause before you can handle the effect...
Having spent years working with the lifecycle methods that are available in class-based components, I'll be the first to tell you that they can, at times, cause major headaches. But the Hooks team seems to have decided that the way to cure the headache is to cut off the head.