Skip to content
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

why does React.Children.only throw? #1728

Closed
oriSomething opened this issue Jun 21, 2014 · 3 comments
Closed

why does React.Children.only throw? #1728

oriSomething opened this issue Jun 21, 2014 · 3 comments

Comments

@oriSomething
Copy link

i find my self not using React.Children.only because it's makes thing more complex and also it seems there are V8 performance issues (if i got it right).

i've found my self writing a component that need to react different if children is an array or a react element or an undefined. and using try & catch made things more complex for this issue. it would be nice if there will be a React.Children.isOnly that returns a boolean. but i seems to me that i'm missing something.

@petehunt
Copy link
Contributor

If you can provide specific use cases this would be helpful so we can look at your specific situation. In general we discourage introspecting your children and instead passing a JS object that describes the parameter in a prop.

You can also use propTypes to limit what types of children can be passed to you.

@oriSomething
Copy link
Author

i creating kind of layout manager. i can't really show the code now. but i can say that in the end i found that React.Children.map can suit better.
still i think it's better that will be a React.Children.only version that doesn't throw because some performance issues and it will make the code more complex.

@sophiebits
Copy link
Collaborator

React.Children.only is meant for asserting that you have a single child, not for testing whether you do – if there are expected cases where you don't, you shouldn't use that method. I can almost promise that regardless of what you do, React.Children.only will not significantly affect performance for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants