-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Setting Unknown Attributes #9477
Comments
Please make sure to leave a comment here if you want to take it. |
cc @aweary in case you were looking for something fun 😄 |
Hey @gaearon I would like to work on it. |
I can give a hand too 🖐 |
What's your take on |
I think it's a bad idea, it's pretty easy to let some props pass through without wanting too ( IMHO, a custom syntax (like a prop prefix) would be much better. |
I think we should still warn on casing typos. I can hardly imagine this ever being intentional. |
I think the rendered html should have |
I think it’s important that everyone commenting here also reads #140. There are plenty use cases for non-standard attributes, and the biggest motivation is enabling those + dropping the need for whitelist in production. I’m happy to debate the details of how we approach this, but I don’t want to turn this thread into a bikeshed on whether or not it is useful. |
@islautin I don’t mean no disrespect, but I would really prefer that whoever jumps on this has contributed to React before. This is a fairly involved change, and shepherding PRs from new contributors takes a lot of team time (which we currently are running short of). We use this label for issues more appropriate for first-time contributors. |
Update: @nhunzaker already had a PR for this in #7311, but it got stale. @nhunzaker How much time do you think it’ll take for you to circle back to that PR? If you have other outstanding PRs, which do you feel are blocking you from working on it? |
The scroll-jank PR (#9333) just needs a bit more testing and approval. I was planning to write some DOM fixtures for media elements, but that could wait. The DOM Factories PR (#8356) is complete work, it just needs to be integrated into the new build system on master and the old build system on 15.6-dev If we want to get this in as fast as possible, I could definitely switch gears. |
Misspellings will no longer be caught. Perhaps disabled by default, since this is an edge case for most. |
I don’t see why they wouldn’t (we can still warn for misspelling on things React is aware of, like |
Perhaps @spicyj could take over it?
Perhaps @flarnie could take over it? No pressure to either of you 😄 Just noticed it seems like most of the work is done, and it’s now at approval / cherry-picking stage where it would make for the team to jump on them. |
@gaearon & @nhunzaker I can take over integrating the DOM Factories PR with the old/new build systems - that way @nhunzaker will be free to either focus on #9333 or help with this issue. Thanks for asking. :) |
Sounds good, thanks @flarnie! |
As a pointer to implementors, I think the tests that will be affected are all in the "unknown attributes" suite here: https://github.com/facebook/react/blob/master/src/renderers/dom/shared/__tests__/ReactDOMServerIntegration-test.js#L434 I think they are pretty self explanatory, but if not, feel free to ping me! |
Also, one weird quirk occurs to me: with this patch, I think you still won't be able to add attributes with the names |
@gaearon, the first 5 issues in that list have already been taken by someone and in some cases a PR submitted. That's a lot of reading and digging to come up empty handed. Is there a more efficient way of finding issues that no one has claimed yet? |
No—there aren’t that many bugs in React, and we also don’t add a ton of features. So these quickly get taken, and most contribution opportunities are in ecosystem libraries, and related tooling. And of course we appreciate people helping provide support to other people (who make honest mistakes) both in issues and on StackOverflow and chats. |
(As a side note I want to slightly change the label system for claimed issues, but that’s a separate discussion. Please file a new issue and I’ll reply to you there.) |
@gaearon I agree that this is really useful, I meant that you could automatically append |
Some widely used libraries which depend on React have used syntax that ends up passing non-standard props to default React components like 'dom' and 'div'. For example: ``` // where this.props contains attributes like 'foo' return <div {...this.props} />; ``` Since we started throwing warnings for this syntax in Reactv15.2 some libraries have not upgraded past v15.2. Now, because of deprecations in 15.5, some libraries will only work with Reactv15.5, and this causes a conflict when other libraries are pinned at v15.1. The overall effect is that either there are version conflicts or the "unknown prop" warning is thrown all over the place, and users of these libraries can't fix the warnings. See facebook#9466 for more context. We are deduping this warning in hopes that it allows more library authors to update to the latest version of React. React v16.0 may take a different approach to this issue. For some related discussion, see facebook#9477 **Test Plan:** - Added a unit test - Manually tested with a fixture that was not committed; https://gist.github.com/flarnie/db011bf54206f30b9983cd4dc674c82e
We are currently warning about “unknown properties” in the DOM.
For example if you render:
you’re going to see a warning from React, and
foo
won’t actually turn up in the DOM.People have wanted support for custom attributes since forever: #140. Now that we've actually been warning for a whole release, I think it's a good time to flip this behavior, and to set any unknown attributes on the DOM instead of skipping them.
So the goal is that you would actually see
<div foo="bar" />
in your DOM.There is just one caveat: we still haven't updated all FB callsites to fix this warning. Ideally we want to stay synced with open source version of React, but I don't want React 16 to be delayed because of this, nor do I want delaying this change until React 17. So I think we should bite the bullet, introduce an internal feature flag that will differ for our FB builds, and enable the new behavior in the open source version. Some time during React 16 we’ll finish updating our code, and remove the conditional code path.
I don’t think anybody on the team has time to work on this right now, so I’d love this to be a community contribution. Requirements as I see them:
ReactDOMFeatureFlags
. Something likeshouldSetCustomAttributes
. Set it totrue
.shouldSetCustomAttributes
isfalse
. Make sure tests still cover this case (you can override feature flag in tests—see existing tests concerning feature flags for how to do it).setAttribute
for any unknown properties (rather than skipping them like we do now). Add tests for it. Those tests shouldn’t need to touch the feature flag (since it’s the new default behavior). Make sure this works both for SVG and HTML.true
) since we don’t use server rendering ourselves.Please let me know if you’d like to take this. It could turn out a little complicated (there won’t be a lot of guidance from us on this so we probably can’t coach a completely new contributor for this task). But if you sent a PR or two to React, you should be able to do it.
--
Update: @nhunzaker already started a PR on this a while back (#7311) and might be able to rebase it. Let’s discuss the plan more in more specifics below (#9477 (comment)).
The text was updated successfully, but these errors were encountered: