Remove JSX tag whitelist; use case instead

[sophiebits]

With this, tags that start with a lowercase letter are assumed to be built-in and have React.DOM prepended; uppercase tags are assumed to be user-defined and are left as-is.

Not sure if we want to do this but perhaps we do!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[syranide]

👍 related #1539

[syranide]

If we go this route, it might make sense to separate the two in the parser already. I.e, something like XJSDOMNodeName and XJSComponentName, would allow us to apply separate parsing rules and warn accordingly.

[syranide]

Btw, an argument that might lend some legitimacy to this is; HTML tags use lower-case and hyphen exclusively with the exception of SVG, the bastard child that also features case-sensitive camelCased tags and attributes, but the first char is always lower-case. Web components which are undeniably coming and fight for the same namespace as JSX, must also use lower-case and at least one hyphen.

So basically, anything that starts with a lower-case char might be reserved (by the standards or web components) outside of our control, and all work pretty much the same way (DOM nodes/elements). However, there are zero valid HTML tags that start with an upper-case char, meaning that we have that entire namespace for ourselves, no definitions required, no possible conflicts.

This would also mean that we can apply different parsing rules, it doesn't make sense to use member expressions for HTML tags, it also doesn't make sense to allow hyphens for JSX tags but we want member expressions (@jeffmo right? :P). We can enforce both at parse time.

What we end up with is razorsharp, zero config, division between the DOM (lower-case) and React's happy-fun-land (upper-case). As @jeffmo pointed out, it wreaks of convention smell and I agree, but it does work out fantastically well in the end for something that might otherwise really be a rather sticky situation.

It's also a naming convention that, at least for me, feels natural in React and is something I have self-imposed from the start.

[benjamn]

I'm a big fan of this idea.

[zpao]

I personally am not a big fan of this idea. It's not entirely uncommon to pass a component type around and then construct it later. (var comp = this.props.component; do something with <comp ...>)

[syranide]

@zpao Not saying you're wrong, but... var Comp = this.props.component; do something with <Comp ...>?

Perhaps the most important thing to keep in-mind, if we want to support web components, what do we do? Do we envision ReactComponentComponents actually being web components in the future? If so it makes sense not to do this perhaps. If we don't believe that; unless we find a non-obtuse way of dealing with web components we may be leaving a lot of users in the cold if they have to register and require them.

[sebmarkbage]

I like this. I think that it's the only sane way to do this. I think that @jeffmo is the only one against it at this point. Not sure how to unblock.

Web components are unrelated since they're not ambiguous (requires a dash).

[syranide]

@sebmarkbage Here you go 🔨 hehe. On a more serious note, I generally agree with @jeffmo on this, but it's a very neat solution to a very tricky problem unless we're going a different route (i.e. explicitly "wrap" each web-component as a react-component).

[sophiebits]

We agreed today that we'll do this; I'll rebase when I get a chance.

[syranide]

👍

[zpao]

Are we going to do this before 0.12?

Edit: ah, saw the milestone.

[sebmarkbage]

Yes

[syranide]

Doesn't this also apply it for member expressions?

[sophiebits]

I need to test though it sounds like @sebmarkbage is moving some stuff around here anyway now that #2287 is in. We decided that tags with - and : are always treated as native tags (i.e., strings) and member expressions (with .) are always JS references, regardless of capitalization.

[syranide]

Sound 👍

PS. Although I'd check for member expression and not for ..

[sophiebits]

@sebmarkbage did this in c4658c1.

[zpao]

Removing "accepted" so my bookmarked search for things I need to merge internally works right. (and just found out I can add is:merged and that would have worked too... I'm learning)