Allow jsx to write tags with bracket, instead of dot, notation.

[actionnick]

This will allow for hyphenated tags in the future as something like
React.DOM["font-face"](content, mountNode)
instead of the invalid
React.DOM.font-face.(content, mountNode)
Many SVG tags have hyphenated tags so this would be a good thing to have.

[sophiebits]

Would be nice to share logic with quoteAttrName in xjs.js.

[petehunt]

I believe this will break closure compiler minification. I think this would be a good idea if we could detect if it is not a valid JS identifier (ie. contains -) and use this only for invalid identifiers

[actionnick]

@spicyj How does this look?

[sophiebits]

Maybe '[' + JSON.stringify(nameObject.name) + ']' here?

[sophiebits]

Looks pretty reasonable. I'll let @jeffmo review and merge.

[syranide]

Going by how everything HTML-related is camelCased in JavaScript rather than hyphenated, doesn't it simply make more sense to call it fontFace? Seeing as we can only apply it to HTML/namespaced tags.

[actionnick]

@syranide SVG spec defines a few tags that are hyphenated such as this one.

[syranide]

@nschaubeck Right, but lowercase+hyphens is the HTML/markup naming convention, the general naming convention for HTML-related stuff in JavaScript is camelCased like all the official HTML APIs are.

[actionnick]

@syranide So are you saying that JSX shouldn't support hyphenated tags? Or are you saying that it should supper camelCased version of hyphenated tags? Do those have to be mutually exclusive? JSX isn't a standard JS HTML API, it's an intermediary markup of sorts, so it makes sense to have this support to me.

[syranide]

@nschaubeck My point of view (I'm not an official dev) would be that it might make sense for component-name to translate to componentName. The style-object supports that notation (I think?), but then again, HTML5 which would be the best guide to follow, the new data- attributes do not support it, data-key-name is accessed as keyName in JS. They even explicitly disallow ambiguity as data-keyName is accessed as keyname.

Personally I see two big issues:

1. component-name and ComponentName are identical, it introduces a stylistic preference to something that doesn't need it/shouldn't have it.
2. It's very weird that component becomes component, but component-name become ComponentName.

Is it weird to separate from the standard? Kind of, but we already have and JSX is not HTML, it's JavaScript and it's just sugar. So in many ways it makes sense (to me) for the notation to be JS-style (nodeName) as opposed to HTML-style (node-name), and not to deviate from that and open up the possibility to choose.

Side-note, the data--attribute in React does expect data-key-name right? (@zpao, @spicyj) Although that is not necessarily a concious decision.

[sophiebits]

Closing in favor of #1539 which does the same thing and is a little cleaner -- thanks for sending this in though!