React: Any reason to use "null" instead of "undefined" for default state? Using default would allow using es6 default values

[ruifortes]

Not really an issue but...
Any reason to use "null" instead of "undefined" for default state?
Using default would allow using es6 default values

[gaearon]

Can you show the code? It's not clear what you are referring to.

[ruifortes]

well..it would be nice to write something like

    var {state={} } = this

    var btnClass = classNames({
      'btn': true,
      'btn-pressed': state.isPressed,
      'btn-over': !state.isPressed && state.isHovered
    })

but of course ...this is definitely not an issue :)

[gaearon]

The state is either there or not. It can't change during the lifecycle. Is this code inside a mixin? Otherwise I don't understand why you'd need to support both use cases (where it exists and where it doesn't).

[aweary]

I think what @ruifortes is trying to do is use ES6 defaults which only work if the value is undefined. Bad example, but say you want to log some properties on state with a general logging function

function logSomeValueFromState(state = {}) {
  console.log(state.value)
}

class Hello extends React.Component {
render() {
    // This throws since `null` doesn't trigger the default value in `logSomeValueFromState`
    logSomeValueFromState(this.state)
    return <div>Hello {this.props.name}</div>;
  }

If state is undefined it will default to an empty object and this would log undefined, but if state is null it doesn't use default params and this would throw an error.

[ruifortes]

I'm kind of embarrassed now for mentioning something like this.
It's just that es6 destructuring assignment default values (at least in babel) regard null as a value.

[aweary]

It's a reasonable question, though I imagine changing it now would be breaking for a lot of users using checks like this.state !== null

[gaearon]

It would be bad to allocate an empty objects for every component that doesn’t have state just in case somebody decides to pass this.state to a function with the knowledge that the current component doesn’t have state 😉 . So I’ll close this but feel free to continue the discussion. Please let me know if I missed an important common use case here. (I understand how ES default arguments work, I just don’t see why you’d pass this.state somewhere if you know your component doesn’t have state.)

[ruifortes]

here goes my contribution to the project :-P

[gaearon]

If you’d like to contribute, watch out for good first bug issues!

[satya164]

@gaearon

It would be bad to allocate an empty objects for every component that doesn’t have state

I think he meant to allocate undefined instead of null, not empty object.

[gaearon]

Ah, sorry, you’re right, I misread one of the comments.
I still don’t see a compelling use case here.

Why would you write var {state={} } = this in a class where you know state does not exist?

[aweary]

You can have a situation where you don't provide an initial state, and setState is called in a timeout. If you were passing this.state somewhere for, say, logging purposes, it would be null until that timeout resolved. If it was undefined you could use a default argument for your logger and avoid null checking for property access. Again, this is probably a corner case that is easy to handle, so I'm not recommending it as a supported use case per se, just trying to illustrate what some users might be trying.

[gaearon]

You can have a situation where you don't provide an initial state, and setState is called in a timeout.

Oh, I see. For some reason I thought we enforced that you can’t call setState unless you also provide initial state but seems like I was wrong!

Let’s keep this closed for now because it seems like benefit is very very minimal, and other issues have much higher priority. If there is enough support behind this and more people ask for this, we can reconsider.

[aweary]

Oh, I see. For some reason I thought we enforced that you can’t call setState unless you also provide initial state but seems like I was wrong!

That seems like a reasonable assumption. Is there a good reason to possibly require this behavior in future versions of React? I'm not sure.

Let’s keep this closed for now because it seems like benefit is very very minimal, and other issues have much higher priority. If there is enough support behind this and more people ask for this, we can reconsider.

Either way, I don't think changing from null to undefined would be worth the breaking change (any check that is checking state !== null or state === null would break).