Add dangerouslySetDefaultInnerHTML

[syranide]

dangerouslySetInnerHTML is a poor fit when trying to provide initial children for other libraries to consume, while safe as long as you don't update the value, it's not very sanitary and in some ways relies implementation details. dangerouslySetDefaultInnerHTML works just like value vs defaultValue, as you would expect.

Should probably be named dangerousDefaultInnerHTML, but I kept the current naming convention until #2257 is resolved.

[sebmarkbage]

Not sure this convenience is needed. getDOMNode().innerHTML works and provides an indication that you're breaking out of the abstraction. If we add this, shouldn't we also provide a way to generate default content in a safer way? Such as using ReactElements?

[syranide]

@sebmarkbage getDOMNode().innerHTML is not strictly equivalent though as it is not batched with the rest of the updates, it will also be a problem when web workers lands? (unless I misunderstood your comments about web workers and DOM access)

[sophiebits]

Also not sure I see the value in this. dangerouslySetInnerHTML is sort of an escape hatch already and you can always continue to pass the old value if you don't want to blow away manual (or contenteditable) changes. You can also set innerHTML manually from JS, as mentioned already, which is almost the same. :)

Going to close this out but reopen if you feel strongly.

[syranide]

@spicyj I don't really feel much at all about this, but it strikes me as a bit odd when we promote "easy escape hatches" as an important feature (I would argue dangerouslySetInnerHTML is an important ingredient in that) that we still leave it up to the user to cache the HTML in state or guarantee that props used in the HTML aren't mutated. When really, setting a default innerHTML value is what they should be doing.

Yeah .innerHTML works, but is also not included in server-rendering.

Anyway, don't feel strongly, it just seems a bit odd.