React: Way to disable the getInitialState warning in ES6?

[probablyup]

I really like the convenience of the getInitialState() API in ES5 react, so I decided to reimplement it in a simple wrapper around React.Component, but I get an annoying warning. Is there a way to disable this warning, since I'm doing it intentionally and providing my own functionality?

[jimfb]

No, short of forking React, there is currently no effective way of disabling the warning. The problem with using getInitialState() is that even if you disabled this warning for yourself, if you ever decided to share your component outside of your environment, they would start getting the warning. Better to just avoid that function name. There are plenty of other names to choose :P.

You can achieve the same thing as getInitialState() by defining a constructor that sets state.

constructor(props) {
  super(props);
  this.state = {/*whatever*/};
}

[probablyup]

I'm aware, and that's why I made the abstraction -- it's a lot cleaner than writing constructor() and calling super() for that one thing (in the subclassed children).

Alrighty then, thanks.

[aldendaniels]

:+1: I'd like to name a method on my component getInitialState(). Of course I could name it something else, but it seems odd that React should continue to warn about this since it's a perfectly valid method name for a class.

[jimfb]

@aldendaniels We warn because 99% of the time, it's a mistake by a user upgrading their ES5 class to an ES6 class. The benefit of the warning greatly outweighs the downside of reserving that one function name. When ES5 create class is officially deprecated/gone (not in the near-term future), we can unlock that function name.

[syranide]

@jimfb Just an idea, what if we warned after the constructor has finished and only if state does not exist on the instance. That should satisfy both problems?

[jimfb]

@syranide Sure. Super low priority (so low that I'm not sure it deserves an open issue), but if someone feels strongly and wants to submit a PR, I don't see any reason not to accept that solution.

Side note: Using inheritance within a react component hierarchy is a bit of an anti-pattern anyway. If you don't directly extend React.Component (ie. you extend your base implementation that calls getInitialState()), I think a few of the linters won't give you warnings about other bugs. Also, I'm not sure it's wise to be re-using the names of es5 lifecycles, but it sounds like there isn't a technical reason that it wouldn't work, so I'm fine with allowing it.

[syranide]

Using inheritance within a react component hierarchy is a bit of an anti-pattern anyway.

@jimfb Agreed, I personally see _some_ sense in allowing this for this.state = this.getInitialState() in the constructor and it would allow you to reset uncontrolled components with this.setState(this.getInitialState()) or something similar. I don't really care much myself either, but I feel like there are some _not so bad_ uses for this.

[jeroenransijn]

I think it should actually be a best practice to follow what @syranide pointed out in ES6 classes. I would vote for having this approach: this.state = this.getInitialState() and this.setState(this.getInitialState()). I believe more in the reasoning of throwing an error in ES6 when there is a getInitialState, but this is not assigned to state in the constructor, not sure how hard this would be to catch. This would bring ES5 and ES6 react conventions more close to each other, instead of people using ES6 or upgrading to ES6 renaming all of their methods. Just my 2c.