Could dangerouslySetInnerHTML.__html be null or undefined?

[victor-homyakov]

In following JSX fragment I should guarantee that this.props.description will never be null or undefined:

<div dangerouslySetInnerHTML={{__html: this.props.description}}></div>

Otherwise https://github.com/facebook/react/blob/master/src/browser/ui/ReactDOMComponent.js#L74 throws an error although construction is correct:

`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`

Should invariant instead of props.dangerouslySetInnerHTML.__html != null check for '__html' in props.dangerouslySetInnerHTML?

[sophiebits]

Someone else mentioned this being surprising to me too.

[chollier]

I've been experiencing the same issues recently

[syranide]

As far as I understand it, the idea is that {__html: ...} is basically the equivalent of a HTML-type. You're not meant to use it as <div dangerouslySetInnerHTML={{__html: this.props.description}} />, but as <div dangerouslySetInnerHTML={this.props.description} /> so that you cannot accidentally pass unsafe data. So description should be null or {__html: ...}, in this model it does not make sense to have {__html: null}.

[sophiebits]

@syranide That doesn't mean that people won't write it as dangerouslySetInnerHTML={{__html: this.props.description}} – doing so is even pretty reasonable if you're careful about naming your vars/props and do dangerouslySetInnerHTML={{__html: this.props.descriptionHTML}}.

[glenjamin]

The simplest workaround is to coerce into an empty string with dangerouslySetInnerHTML={{__html: (this.props.description || '')}}.

+1 for having React do this internally.

[nicolashery]

Got surprised by this today, upgrading from react 0.12.2 to react 0.13.2.

Was it a "bug" in 0.12 (i.e. it shouldn't have accepted {__html: null}), or is it a bug in 0.13?

Anyway, will use {__html: (this.props.description || '')} as suggested by @glenjamin, just wanted to point out that it seemed to "work" in 0.12.