Should throw error when null or falsy values are passed as event listeners

[amasad]

Null values for event listeners fail silently. http://jsfiddle.net/2BCLQ/1/
Falsy values for event listeners fail silently http://jsfiddle.net/2BCLQ/2/

[sophiebits]

I'm afraid this behavior is intentional so that you can write things like onChange={isEnabled && this.handleChange}, and I don't think we're going to change this.

[amasad]

this explains the falsey part but not why failing silently for null value. Passing null values as event listeners should at least be warned.

[sophiebits]

Similarly, you could write onChange={isEnabled ? this.handleChange : null} or something along those lines. We've felt like that is the most helpful behavior; it's convenient to have falsey handlers be ignored, just like null and false don't render anything when included in an element's children.

[amasad]

Right. Have you thought about standardizing on boolean false instead? onChange={isEnabled ? this.handleChange : false} onChange={isEnabled && this.handleChange} works fine with that.

Maybe not worth breaking change, but we tripped over this a couple of times where someone changes a method name or a typo etc.

[sophiebits]

I personally find it much weirder that false is ignored; it doesn't surprise me that null is. With props, we consistently assume that undefined is equivalent to not specifying the prop at all (like when merging in the result of getDefaultProps) so it would definitely be a change to treat undefined as invalid here.

[akre54]

I understand the reasoning behind keeping the events and props interface similar but this has bit me a few times on stupid typos and refactorings. React is usually very good about failing early and loudly in dev for other gotchas, and this seems like an odd oversight.

IMO null and false are both fine sentinels for "this space intentionally left blank" but undefined is Javascript's idiotic way of handling both "not here right now" and "was never here". It'd be nice to have this addition.