expose htmlattribute -> htmlAttribute mapping in react-dom #14268
Conversation
There are a ton of libraries that are reimplementing this functionality where we can make things easier on the community by simply exporting what react-dom itself uses for minimal bundle cost
|
ReactDOM: size: 🔺+11.2%, gzip: 🔺+11.1% Details of bundled changes.Comparing: c954efa...f8ef9ee react-dom
Generated by 🚫 dangerJS |
|
Alternatively if we don't want to make react-dom itself bigger, it could be extracted and moved to a different package or an alternative import similar to |
Why? That seems like the problem. For example, |
|
Because React warns if you pass through an attribute it doesn’t recognize.
Many libraries try to do filtering to prevent this since end users
frequently complain when they see console warnings. Making the list that
React uses for the warning importable and deduped by the various libraries
is a nice gesture, although just dropping the warning would be better IMO.
…On Thu, Nov 22, 2018 at 9:45 AM Dan Abramov ***@***.***> wrote:
There are a ton of libraries that reimplement this functionality
Why? That seems like the problem.
For example, styled-components reliance on this is a conceptual issue
with its *API*. Not with the implementation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14268 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAiy1ts-jum3Nakrp80Y_QUOX-jm9mozks5uxsavgaJpZM4YoEEB>
.
|
This hasn't been true since React 16. React lets you pass any attributes through. It does warn for invalid casing of supported attributes. However, you should just let React do its thing, and not try to detect it at a library level. The root of the issue, to my knowledge, is that some libraries attempt to filter DOM attributes. That's a problem by itself because it doesn't let people pass custom attributes to the DOM. If those libraries don't attempt to do that, then the whole thing is not an issue. I'm saying that attempting to do filtering before React is a design flaw in these libraries. That they need to fix. We shouldn't be making it more convenient to create more libraries with this design flaw. Am I missing something? |
I would love to not have to, believe me. All of these sort of activities are ultimately workarounds for deficiencies in prop handling via JSX when HOCs are involved. If namespacing could be seriously considered, styled components et all could drop all prop filtering activities except plucking out its own namespace. |
That's also not accurate. This warning is emitted for "linkStyle", for example: |
Right, but it tells you what to do. If you pass More importantly, this warning occurs for any camelCase name outside of the ones supported by React. I don’t see how exporting a map of known attribute would help you with it. Maybe let’s start from another end. If React did provide an export like this, what would you do with it? In development and in production. You describe it as a common need but the only library I consistently see bit by this is styled components — because its API decisions early on relies on there existing a difference between “DOM props” and “other props” which is not the case anymore in React. |
|
Let me try to explain it differently. React doesn’t depend on this list for production behavior. However, my understanding is that styled components would like to. That’s something we’d prefer to discourage. It’s a feature that you can do If a library limits this expressiveness by dividing props into “DOM props” and “non-DOM props” it’s the library’s choice. But it’s not what people expect primitive React components like In fact relying on this list in production turns React supporting any new DOM attribute into a potential breaking change. Such as I don’t have a great answer for what Styled Components should do. I think my personal favorite option is to confine all style-only parameterization to a single prop, like Hope that makes some sense. |
There are a ton of libraries that reimplement this functionality, leading to unnecessary bundle weight. We can make things easier on the community by simply exporting what react-dom itself uses.