[New Docs] "DOM Elements" reference and cleanup#7983
[New Docs] "DOM Elements" reference and cleanup#7983lacker merged 13 commits intofacebook:new-docsfrom
Conversation
|
|
||
| The following HTML elements are supported in `React.DOM.*`: | ||
| The `checked` attribute is supported by `<input>` components of type `checkbox` or `radio`. You can use it to set whether the component is checked. This is useful for building controlled components. | ||
|
|
There was a problem hiding this comment.
Do we have any place in new docs where controlled vs uncontrolled is explained?
There was a problem hiding this comment.
That's pending on the "forms" doc existing. @ericnakagawa said he'd have that in a PR later today
docs/docs/reference-dom-elements.md
Outdated
|
|
||
| ### className | ||
|
|
||
| Since `class` is a reserved word in JavaScript, React elements use `className` instead. |
There was a problem hiding this comment.
Gotcha: except if you use web components.
Also, the real reason is just historical. These days it being reserved word doesn't matter and many libraries use class for the same purpose without any issues.
So maybe it's fine to just punt on explaining instead of blaming JavaScript.
There was a problem hiding this comment.
ok I just stopped trying to explain
| ### dangerouslySetInnerHTML | ||
|
|
||
| `dangerouslySetInnerHTML` is React's replacement for using `innerHTML` in the browser DOM. In general, setting HTML from code is risky because it's easy to inadvertently expose your users to a [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) attack. So, you can set HTML directly from React, but you have to type out `dangerouslySetInnerHTML` to remind yourself that it's dangerous. For example: | ||
|
|
There was a problem hiding this comment.
Let's also mention the result must have __html field for extra explicitness? Otherwise it's not clear what it means.
There was a problem hiding this comment.
ok added this mention
docs/docs/reference-dom-elements.md
Outdated
|
|
||
| ### key | ||
|
|
||
| `key` in React doesn't correspond to anything in HTML. It's an optional unique identifier for components in lists. Assigning it a key that persists makes sure the component stays. You can read more [here](/react/docs/reconciliation.html). |
There was a problem hiding this comment.
It's not quite optional. React loudly complains if it is missing.
Giving it a key just means component gets reordered efficiently. It does not determine whether it "stays".
There was a problem hiding this comment.
just removed this section as mentioned below
docs/docs/reference-dom-elements.md
Outdated
|
|
||
| The `onChange` event behaves as you would expect it to: whenever a form field is changed, this event is fired. We intentionally do not use the existing browser behavior because `onChange` is a misnomer for its behavior and React relies on this event to handle user input in real time. | ||
|
|
||
| ### ref |
There was a problem hiding this comment.
Can we group key, ref and put them at the beginning?
They have completely different semantics and are handled by React itself. They also work on custom components unlike any other attributes here.
There was a problem hiding this comment.
Ah, you're right - actually I don't think key and ref belong in this document at all. This document is supposed to just be differences between the regular DOM, and the React DOM, and key and ref are more like React features than things related to DOM elements. Since we already have other docs that go into great detail about key and ref, I just removed this brief sections.
docs/docs/reference-dom-elements.md
Outdated
|
|
||
| ### suppressContentEditableWarning | ||
|
|
||
| This is used to suppress the warning when using `contentEditable` and `children`. |
There was a problem hiding this comment.
It's confusing why warning exists then. Maybe mention "by projects like Draft.js that manage contentEditable manually"
docs/docs/reference-dom-elements.md
Outdated
|
|
||
| ### value | ||
|
|
||
| The `value` attribute is supported by `<input>` and `<textarea>` components. You can use it to set the value of the component. This is useful for building controlled components. |
There was a problem hiding this comment.
Maybe also good to mention defaultValue and defaultChecked as their uncontrolled equivalents?
docs/docs/reference-dom-elements.md
Outdated
| ``` | ||
|
|
||
| #### SVG elements | ||
| ## All Supported SVG Elements |
There was a problem hiding this comment.
This is incorrect. The list below is the list of SVG elements for which we have shortcuts in discouraged React.DOM factories.
However if you use JSX (of if you pass strings to createElement and avoid React.DOM factories), all SVG elements are supported out of the box. There is no whitelist for them.
There was a problem hiding this comment.
Ah OK - I did not see that those were different things. In that case I think this section should just not go into the doc, along with the React.DOM-specific stuff. Removed it
|
OK i responded to all comments |
docs/docs/reference-dom-elements.md
Outdated
| ### className | ||
|
|
||
| #### SVG elements | ||
| Most React elements use `className` instead of `class`. Web Components still use `class`. |
There was a problem hiding this comment.
"Most React elements" is a bit weird.
Maybe:
To specify CSS class, use the
classNameattribute. This applies to all regular DOM and SVG elements like<div>,<a>, and others.If you use React with Web Components (which is uncommon), pass
classinstead.
docs/docs/reference-dom-elements.md
Outdated
| The following SVG elements are supported in `React.DOM.*`: | ||
| ### dangerouslySetInnerHTML | ||
|
|
||
| `dangerouslySetInnerHTML` is React's replacement for using `innerHTML` in the browser DOM. In general, setting HTML from code is risky because it's easy to inadvertently expose your users to a [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) attack. So, you can set HTML directly from React, but you have to type out `dangerouslySetInnerHTML` and pass an object with a `__html` key,to remind yourself that it's dangerous. For example: |
There was a problem hiding this comment.
Missing space before "to remind"
|
|
||
| function HelloWorldComponent() { | ||
| return <div style={divStyle}>Hello World!</div>; | ||
| } |
There was a problem hiding this comment.
Can we have two separate examples here? One should be simple and show basic style usage. The second can be preceded by "Note that styles are not autoprefixed. To support older browsers, you need to supply corresponding style properties."

This creates one "DOM Elements" reference doc whose goal is to explain all the little DOM tweaks that React makes. This doc replaces a few different previous reference docs, and also a number of tips.
I also removed all the tips and reference docs that are now superceded. All the tips are dealt with now, and except for the error decoder, all the old docs have some PR out that replaces them.