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

Remove sliceChildren #9109

Merged
merged 1 commit into from
Mar 6, 2017
Merged

Conversation

aweary
Copy link
Contributor

@aweary aweary commented Mar 4, 2017

Another file that looks unused. It's not exposed via any public API like React.Children and is not required anywhere internally in react, react-native, or react-art.

Similar situation as #9107. Looks unused, but maybe not 😄

Copy link
Collaborator

@sophiebits sophiebits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@aweary aweary merged commit 0c1f515 into facebook:master Mar 6, 2017
@sebmarkbage
Copy link
Collaborator

Well this is used by code internally at FB so maybe we should expose it publicly rather than just keeping it as an internal helper?

@gaearon
Copy link
Collaborator

gaearon commented Mar 7, 2017

It predated toArray. I think we should just change internal callers to use toArray instead.

@sebmarkbage
Copy link
Collaborator

sebmarkbage commented Mar 7, 2017

Currently the helper is simple but we could optimize it more on our end since we don't have to first create a large array with adjusted/concatenated keys and new elements and then take a small subset of those.

@sebmarkbage
Copy link
Collaborator

sebmarkbage commented Mar 7, 2017

Like one of our use cases is:

<div>
  {sliceChildren(this.props.children, 0, 1)}
</div>
<div>
  {sliceChildren(this.props.children, 1)}
</div>

This is really inefficient for any significant number of children. Especially if they're nested.

The toArray helper was not added as a best-practice but more as a compromise to make it easy when it doesn't matter but it is still terrible for perf.

EDIT: I suppose in this case, this you would reuse the array which isn't not as bad but also not as good as we could make it with a custom data structure.

@gaearon
Copy link
Collaborator

gaearon commented Mar 7, 2017

The toArray helper was not added as a best-practice but more as a compromise to make it easy when it doesn't matter but it is still terrible for perf.

Ah okay. My concern was the opposite: the method really makes you think it's optimized but uses toArray under the hood.

@sebmarkbage
Copy link
Collaborator

Maybe we should just unify on lodash's lazy evaluation chained "Seq Methods".

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

Successfully merging this pull request may close these issues.

5 participants