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
Remove React.Children.only from theme provider #1325
Comments
|
Because the ReactDOM.render(
<ThemeProvider>
<div />
<div />
</ThemeProvider>
)is basically this: ReactDOM.render(
<div />
<div />
)And that's not valid input for render. So, we use React.Children.only to ensure we only have one child (That's the main use case for that function) and yell at you if you try to have more. Sorry for the troubles there, but it's for everybody's benefit! |
|
I have multiple different themes throughout my app. I don't only use the theme at the top level. Also, the example you gave isn't valid, but as of React 16, this is: ReactDOM.render([
<div>DIVE ONE</div>,
<div>DIVE TWOOOOO</div>
], anchor)Are you sure that what I'm suggesting won't work in React 16? There are a lot of different use cases and I don't think that |
|
You are right, my wording was bad, I've updated my previous comment: The ThemeProvider doesn't belong to the top, but it can be at the top. Of course React v16 supports Arrays, but we're not dropping support for React <v16 given how many people still use those versions. We might cut a major version in a year or two and drop support, but to be honest I'm not very inclined to drop support for React <v16 at all if the only difference is that the That being said, I'd be happy to hear more about your specific use case, do you have some code that doesn't work solely due to this behavior? |
|
I do. I want to put multiple children under a theme and I currently have to add an unnecessary wrapper I understand that you're trying to protect some newer users of React from making a mistake but in doing so you're limiting some of the potential use cases for If you're really concerned we could add a I understand that you want to support React 15 for another while but that shouldn't hamper users of React 16 of which there are already a lot and more people are upgrading every day. |
|
That's a lot more work than you just putting a |
|
Wrapper divs are a huge annoyance because they have to be styled depending on the context that they're being used in. It's also an unnecessary The only work really required here IMO is to simply return |
|
I'm sure a single wrapper div is going to kill your apps performance 😉 Nobody's talking about the code change, of course changing three lines of code is easy. I can do that in two minutes tops. The problem is what comes afterwards: We gotta update all the documentation and any old blog posts, write a changelog documenting this and the reason for changing it, and once that's done we gotta deal with the dozens of questions we'll get about that weird React error when you try rendering a top-level For what? I don't even know how you're using the |
|
Can you clarify how removing the enforcement breaks backwards compatibility? The way I see it existing users should not see any problem because they already only use a single child and for new users using React 16 it will just work as expected. New users on React 15 will just get an error that can easily be explained in the docs with a note like
I would expect the existing restriction to result in at least as many questions going forward as not having that restriction would for the time being (i.e. not many). And as users upgrade to 16 and beyond, there will likely be more questions from having the restriction than not having it. FWIW I'm not sure but I think |
|
To clarify, here's what I'm seeing in React 15 without the restriction:
Demo: https://codesandbox.io/s/54lr0o8yn And here's what I'm seeing with the restriction:
Demo: https://codesandbox.io/s/zx4k75y304 I don't think either message is more helpful than the other, but the one without the restriction gives the name of the component that returned multiple children whereas having the restriction hides that from the error message but gives a slightly more relevant (but not really helpful) stacktrace. |
|
I couldn't agree more @pluma. |
🤔 @mxstbr I do not believe this is a very compelling reason for Also, we shouldn't be cavalier about inserting unnecessary So, this choice is definitely adding complexity to consuming applications, and the trade-off is to… forgive me, but is it just to shelter junior-level developers who don't yet realize It seems like removing this restriction is a win-win: (a) we get reduced complexity, and (b) junior developers aren't sheltered from learning a fundamental restriction of using React. If the effort needed is the only argument against lifting this restriction, I would be glad to contribute the necessary PRs! 🤓 |
We can get rid of that restriction because ThemeProvider uses stable React Context API and children cannot be top-level element. Fixes #1325.
|
This restriction was removed in this PR: #2706. |
We can get rid of that restriction because ThemeProvider uses stable React Context API and children cannot be top-level element. Fixes #1325.
We can get rid of that restriction because ThemeProvider uses stable React Context API and children cannot be top-level element. Fixes #1325.
…dren (#40223) * styled-components: allow ThemeProvider to have multiple nodes as children styled-components/styled-components#1325 (comment) * styled-components: bump version according to the changes made
It there a reason to have
React.Children.onlyin the theme provider? It seems unnecessary and it makes certain layouts not possible. Why not simply returnthis.props.childrenfrom render?The text was updated successfully, but these errors were encountered: