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

Generate SimpleEventPlugin data structures at runtime #7616

Merged
merged 1 commit into from
Sep 2, 2016

Conversation

vjeux
Copy link
Contributor

@vjeux vjeux commented Aug 30, 2016

We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.

It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)

screen shot 2016-08-30 at 11 30 50 am

screen shot 2016-08-30 at 11 34 33 am

@vjeux vjeux mentioned this pull request Aug 30, 2016
@vjeux vjeux added this to the 15-next milestone Aug 30, 2016
@sophiebits
Copy link
Collaborator

I don't like code that fails the grep test. :\ http://jamie-wong.com/2013/07/12/grep-test/

@vjeux
Copy link
Contributor Author

vjeux commented Aug 30, 2016

@spicyj yeah, it's not ideal. I really don't understand why we have such a convoluted setup of layers of indirections with repeated things to setup event names.

@gaearon
Copy link
Collaborator

gaearon commented Aug 30, 2016

I think the benefit here outweighs the possibility that somebody (us?) would be grepping onClickCapture specifically. Grepping for Capture would be the second thought here, and that works.

captured: 'onLoadStartCapture',
},
},
// Note: We do not allow listening to mouseOver events. Instead, use the
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why was this comment here? I don’t understand what it refers to because mouseOver is defined just below. Is this still relevant and should some version of this be copied to new code?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Must be outdated. We used to not have onMouseOver/onMouseOut but now we do.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought I ported it back but it slept through the several revisions I've done, oops. Good to know it is no longer needed.

@zpao
Copy link
Member

zpao commented Aug 30, 2016

I really don't understand why we have such a convoluted setup of layers of indirections with repeated things to setup event names.

Maybe we should address that and not just try to trim a few bytes off of code that not many understand fully?

@gaearon
Copy link
Collaborator

gaearon commented Aug 30, 2016

Why not do one step at a time?

IMO it would be easier to address when there is less code because it seems easier to me to change data structures in one place rather than all over the file.

@sophiebits
Copy link
Collaborator

Okay. FWIW if anyone wants to understand how the current events work, I am happy to explain it in depth.

@gaearon
Copy link
Collaborator

gaearon commented Aug 30, 2016

I want to. Can we also record this for future generations? cc @kentcdodds

@aweary
Copy link
Contributor

aweary commented Aug 30, 2016

I would also love to know how it works!

@kentcdodds
Copy link

@spicyj, let's chat. Email coming your way :)
Thanks for the ping @gaearon 👍

@kentcdodds
Copy link

As for the grep test, I wonder if you could just add the things you want to grep for as comments at the top of the file with a big comment explaining what's going on in the file (and why it's better to be this way).

@sebmarkbage
Copy link
Collaborator

My concern with meta-programming in general is different. It is crazy difficult to unwind this when you have special cases and encourages you to put everything in the same kind of configuration system even though the particular thing you're trying to fix is a new case that doesn't fit. That's true before and after this change.

I'd rather explode these into the closest point where they're needed to be checked.

For example, does it really make sense for all of these to bubble and therefore require every type of element to be able to handle any event we have? Leading to special cases like all images needing onload.

@gaearon
Copy link
Collaborator

gaearon commented Aug 31, 2016

I don’t feel strongly about collapsing everything here. The thing that seemed odd to me originally when I suggested this is that I can’t imagine us wanting a captured name that isn’t bubbled + 'Capture'. Is there ever going to be such a case?

@sebmarkbage
Copy link
Collaborator

We'll probably need to rethink this strategy regardless because of the explosion of combinatorial options now: #6436

@gaearon
Copy link
Collaborator

gaearon commented Aug 31, 2016

Yes but this will take a while and is not a priority.
In the meantime, it’s nice to shave off some build size with small wins like this.

@sebmarkbage
Copy link
Collaborator

I'll bow out because there is too much brainpower on this PR already. Either way is fine.

I'll just leave it that I don't think this is a good systemic strategy to keep doing. We shouldn't avoid making the hard decisions by making existing code shorter in clever ways and more difficult break apart later when we need to make the hard decisions. We don't even know if this is a net win because this might cause longer module init time, might cause the string ropes to not be interned or whatever.

There's more impactful work to do in this space such as just getting rid of the Capture events and solving the Passive listener case, or getting rid of most of this list by bypassing our event system and passing them through.

We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.

It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
@vjeux
Copy link
Contributor Author

vjeux commented Sep 2, 2016

Fixed the lint issue, the build should now be green. I'd love a final call here, either an accept or that I should drop this pull request :)

@sophiebits
Copy link
Collaborator

Didn't we agree yesterday that it was fine?

@sophiebits
Copy link
Collaborator

(Accepted for the historical record.)

@vjeux vjeux merged commit 1229a23 into facebook:master Sep 2, 2016
acdlite pushed a commit to acdlite/react that referenced this pull request Sep 9, 2016
We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.

It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
stevemao added a commit to stevemao/awesome-pull-requests that referenced this pull request Oct 3, 2016
@zpao zpao modified the milestones: 15-next, 15.4.0 Oct 4, 2016
zpao pushed a commit that referenced this pull request Oct 4, 2016
We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.

It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
(cherry picked from commit 1229a23)
gaearon added a commit to gaearon/react that referenced this pull request Dec 20, 2017
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.

7 participants