Why doesn't ReactJS passthrough "unknown" DOM properties?

[Swivelgames]

For instance, at the moment I have a <label>, that contains a valid for attribute. However, ReactJS (being the baby that it is) doesn't understand this for attribute... Instead of assuming the developer knows what the hell (s)he's doing, it strips it out and leaves a lovely comment about it in the console.

This is incredibly frustrating. I don't want it to strip out attributes that it doesn't understand. I just want it to pass them through. In addition to React's inability to provide adequate support for attributes that have existed since HTML 1.0, what happens when the HTML spec changes and new attributes are available for existing elements?

The bug here and issue being provided is not related to the for attribute, but to React's inability to trust that the developer knows what they're doing. The real bug here is that React assumes the developer does NOT know what they're doing, and strips out unknown attributes out of fear. This is much less than ideal and should be remedied.

[petehunt]

Regarding the specific attribute, React favors the DOM API property names for attributes rather than HTML since they were designed to be usable JS identifiers, so we use htmlFor rather than for, identified it as a common source of confusion and added a warning.

Regarding the rendering of all attributes, there are a number of issues in play. Most importantly, if you use transferPropsTo() you will render meaningless attributes into the DOM leading to a potentially invalid document. Additionally React needs to know specific information about the properties so it can do efficient diffing (i.e. the style property is diffed differently than className) and perform the correct DOM manipulation (using attributes vs properties).

[Swivelgames]

There are a number of different ways I can think of to accomplish this. It's unfortunate that React hasn't gotten over this hump yet. Thanks for the info about the for attribute.

[sophiebits]

It's not that React doesn't trust the developer, but that the various properties behave differently in browsers. For more info about the different kinds of attributes that we need to distinguish between, see the list of attributes/properties here:

https://github.com/facebook/react/blob/master/src/browser/ui/dom/HTMLDOMPropertyConfig.js

It's possible that this can be autodetected (see #1512) but right now we're just shipping the hardcoded list. I'd love to hear other suggestions for what we could do. We already have #140 open to track the ability to customize the custom attribute list.

[syranide]

Have we considered something like an attrs-property? It would pass through any value as-is as an attribute for the DOM (same could be considered for a props-property, although it look kind of ambiguous).

I like it in the sense that it would work like data and aria is going to (soon), and it's use-case is actually very similar (i.e, use unsupported/unofficial attributes) so it kind of makes sense to me.

[xpe]

@petehunt Thanks for explaining. In case it helps others, this Mozilla HTMLLabelElement page documents that htmlFor is the DOM attribute name that corresponds to the HTML for attribute.

[oriSomething]

@Swivelgames by the way, old android (2.x) stock browsers have issues with reserved words as a properties of objects. as much as weird as it sounds, for android 2.3 you'll have to refer to a reserved word as obj['delete'] and not obj.delete, because it will make the js engine to fail. can't say specific about for, but i'll guess it's the same

[chinchang]

@petehunt @spicyj I got React to work with XML type DOM by patching HTMLDOMPropertyConfig.isCustomAttribute function.

https://gist.github.com/chinchang/a66fe3aedaf98b2433eb

All DOM diff-ing works great!