ReactDOMComponent should throw error when provided children for void elements

[jonhester]

Fix for #3367. I removed the ``if(DEV)` block since it's throwing an error now and updated the tests.

[syranide]

Putting all children-logic (createContentMarkup, updateDOMChildren, etc) behind the same check should make sense I think, no point in going through the children-logic if there cannot be children.

PS. Or do we not care in the name of simplicity? cc @zpao @spicyj

[jimfb]

@syranide Well, maybe the proposed if check should be if(props.children == null && props.dangerouslySetInnerHTML == null), since void elements don't have a monopoly on not having children.

@jonhester Thanks for fixing this one so quickly :). Just note that, as per the conversation in #3367, we need to keep it a warning for the 0.14 release, so this probably won't be mergable until 0.15

[syranide]

@jimfb That's tricky because you have to consider prev/next children as well and in a sense that's what the "children logic" is doing internally already, whereas void components will never have children so you can simply skip that part entirely with a single stateless check.

PS. What I'm proposing would be the equivalent of introducing a ReactDOMVoidComponent separate from ReactDOMComponent (except we don't because it's probably a little excessive and settle for a simple conditional instead).

[jonhester]

@JSFB Right, not worried about when it will be merged, and I'm guessing this pull request may need some changes before it's merged, even without merge conflicts. I'm new to contributing to this project, and contributing to open source in general and have been watching the good-first-bug label to try to get some familiarity with the project.

[jimfb]

@syranide Ah, absolutely correct. If such a check is added (to this commit or a future commit), @syranide's logic is correct, we can't just check for the current presence of children, but we could do a void-element check. Probably wouldn't be blocking, but I'm a little curious what @zpao @spicyj would think about the performance vs. simplicity trade-off.

@jonhester Ok, awesome! Glad to have you be a part of the community! Let me know if there is anything we can do to help!

[jimfb]

@jonhester We're merging 0.15 stuff now. As expected, there are a few merge conflicts. Do you want to rebase and we can get this PR ready to be merged?

[jonhester]

@jimfb I'll take care of this now.

[jonhester]

@jimfb Good to go.

[facebook-github-bot]

@jonhester updated the pull request.