0

Can someone please tell me why we need to pass in props to constructor() and super(). I've read a lot of questions regarding this, and also a lot articles too. All saying you should pass in props to constructor and super so that you may access this.props.....

All of my code still works if i do not pass in props to constructor or super. And I can't see any scenario where this would change. Unless i wanted to console log this.props, which could be achieved by console logging this anyway.

Also on a side note, half of the developers I've spoken to, do pass in props, and the other half do not, because they feel they don't need to, yet aren't exactly sure why this happens.

Can anyone shed some light on this for me please?

Thanks

JJJ
  • 32,902
  • 20
  • 89
  • 102
Jay
  • 772
  • 1
  • 6
  • 17
  • Not a duplicate, i'm not asking what the difference is between super() and super(props), i'm asking why my code still works without passing any props to constructor and in turn passing it into super too. – Jay Oct 11 '18 at 11:19
  • Sorry, I don't understand what you're asking. It works because you're not using `this.props` in the constructor. – JJJ Oct 11 '18 at 11:24
  • I can't see any cases where this.props is needed in the constructor – Jay Oct 11 '18 at 12:38
  • So is the real question "why would I use `this.props` in the constructor"? You wouldn't, directly, but you might call a function that uses it. – JJJ Oct 11 '18 at 12:46

1 Answers1

0

The only reason someone needs to pass props is if you want to do something with them in the constructor. Maybe you want to do some computation on props in the constructor -- I'm not sure you can just do that outside of the constructor even though you have access to props without the constructor.

The documentation gives the example of assigning initial state utilizing props in the constructor. In the case of components with local state, this is a good use case for passing props to the constructor.

Additionally, this this SO answer sheds some light on why you need to pass props to super in ES6.

Though, much of this can be disregarded in the sense that you could just not pass props to constructor and initialize your local state without it due to class properties of state and props. Check this Hacker Noon article going through some of the "use cases" of constructor and their alternatives. One thing to point out is that the author mentions that Babel transpiles your code for you to add a constructor -- you just don't see it. Ultimately, I suppose if it is a matter of removing the constructor, you can do it as a matter of preference as also pointed out by Dave Ceddia. Removing the constructor, though, seems to have the added benefit of removing boilerplate and keeping code a bit cleaner.

Ultimately, the author concludes:

We’ve seen that for setting our initial state, we no longer need a constructor (or any other instance property for that matter). We also don’t need it for binding methods to this. Same for setting initial state from props. And we would most definitely never fetch data in the constructor.

Why then would we ever need the constructor in a React component?

Well… you don’t.

[However… If you find some obscure use case where you need to initialize something in a component, both client-side and server-side, you still have an out. There’s always componentWillMount. Internally, React calls this hook right after “newing” the class (which calls the constructor) on both the client and the server.]

So I maintain that for React components: The constructor is dead, long live the constructor!

tlm
  • 952
  • 10
  • 20