Skip to content

Callback data should exclude children #1906

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

Closed
levithomason opened this issue Jul 28, 2017 · 6 comments
Closed

Callback data should exclude children #1906

levithomason opened this issue Jul 28, 2017 · 6 comments

Comments

@levithomason
Copy link
Member

levithomason commented Jul 28, 2017

We currently provide (e, data) in all callbacks. This is very useful as the data usually includes props, significant state, and any proposed new values. However, children should be removed.

We should encapsulate the handling of our callback data in a lib function getCallbackData():

Before

const data = { ...this.props, checked: !checked, indeterminate: false }
_.invoke(this.props, 'onChange', e, data)

After

const data = getCallbackData({ ...this.props, checked: !checked, indeterminate: false })
_.invoke(this.props, 'onChange', e, data)

Why?

  1. It is an opaque data structure that is not to be touched directly.
  2. It is extremely large as it contains the entire tree of ancestors via the _owner._currentElement references.
  3. There are references to children's refs and keys in here, again not something you should be messing with.

The motivation for this issue came form using Storybook with the actions addon. The callback args are logged. They are parsed with a circular JSON safe parser first. Because the children prop is so massive, this gives a huge performance hit.

@stale
Copy link

stale bot commented Feb 4, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Feb 4, 2018
@stale stale bot closed this as completed Mar 6, 2018
@levithomason
Copy link
Member Author

Thanks to @rijk, we have improved how we handle stale issues, see #2761. Reopening.

@levithomason levithomason reopened this May 14, 2018
@stale stale bot removed the stale label May 14, 2018
@stale
Copy link

stale bot commented Aug 12, 2018

There has been no activity in this thread for 90 days. While we care about every issue and we’d love to see this fixed, the core team’s time is limited so we have to focus our attention on the issues that are most pressing. Therefore, we will likely not be able to get to this one.

However, PRs for this issue will of course be accepted and welcome!

If there is no more activity in the next 90 days, this issue will be closed automatically for housekeeping. To prevent this, simply leave a reply here. Thanks!

@stale stale bot added the stale label Aug 12, 2018
@layershifter
Copy link
Member

Unstale, please :cat

@stale stale bot removed the stale label Sep 17, 2018
@stale
Copy link

stale bot commented Mar 16, 2019

There has been no activity in this thread for 180 days. While we care about every issue and we’d love to see this fixed, the core team’s time is limited so we have to focus our attention on the issues that are most pressing. Therefore, we will likely not be able to get to this one.

However, PRs for this issue will of course be accepted and welcome!

If there is no more activity in the next 180 days, this issue will be closed automatically for housekeeping. To prevent this, simply leave a reply here. Thanks!

@stale stale bot added the stale label Mar 16, 2019
@stale
Copy link

stale bot commented Sep 12, 2019

This issue will be closed due to lack of activity for 12 months. If you’d like this to be reopened, just leave a comment; we do monitor them!

@stale stale bot closed this as completed Sep 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants