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

[WIP] Remove event whitelist #11992

Closed
wants to merge 1 commit into from
Closed

[WIP] Remove event whitelist #11992

wants to merge 1 commit into from

Conversation

jquense
Copy link
Contributor

@jquense jquense commented Jan 8, 2018

Not working quite yet, but making some progress. So far the dodgiest thing here is the mapping from Synthetic event to native event. I’m not sure that event.constructor.name is gonna cut it across all browsers.

There is potentially a lot of room for simplify the event dispatch config, if we insist on the convention of onX and onXCapture, you can remove most if not all of the registration name stuff, and map between the types as you go. We do lose the dev warnings about event names but that could be added back as a dev only injection

@jquense
Copy link
Contributor Author

jquense commented Jan 8, 2018

we could also remove some complexity by not having these separate topLevelTypes and use the event name (maybe lowercased?)

if (!topLevelEventsToDispatchConfig[topLevelType]) {
const onEvent = `on${topLevelType.slice(3)}`;
topLevelEventsToDispatchConfig[topLevelType] = {
phasedRegistrationNames: {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this could be simplified to just dispatchType phased/direct if the names don't need to be configurable. I think on the DOM side the convention hold everywhere, not sure about RN tho

@jquense
Copy link
Contributor Author

jquense commented Jan 8, 2018

Sorry, forgot to actually add my thoughts about this:

The idea is that eventTypes become optional and only needed for complex cases where you really need to polyfill something, (like the ChangeEvent). If there is no configuration we assume the event should be treated as following the general pattern in SimpleEventPlugin, e.g. that it is phased, and it's registration names are easily ascertained from the native event type/toplevel type

function getEventsFromRegistraionName(registrationName) {
if (!(registrationName in registrationNameDependencies)) {
registrationNameDependencies[registrationName] = [
`top${registrationName.slice(2)}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Purely for discussion but...

It's really a bummer we need top level event name constants period. There's nothing special about them. We could probably just use the event name that comes from the DOM.

If we dropped top level event name constants, we could avoid binding all events, eliminating overhead for local listeners:
https://github.com/facebook/react/blob/master/packages/react-dom/src/events/ReactDOMEventListener.js#L126

Maybe that's too aggressive. 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I was thinking the same thing. There doesn't seem to be much value to them they are just the event name with 'top' appended.

Copy link
Contributor

Choose a reason for hiding this comment

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

It depends on how it affects bundle size. If we keep them and do something like #11894 then the event plugins can just use the numeric constants for dependencies/switching on events, which would probably compress better.

@@ -115,7 +124,7 @@ function getListeningForDocument(mountAt) {
export function listenTo(registrationName, contentDocumentHandle) {
const mountAt = contentDocumentHandle;
const isListening = getListeningForDocument(mountAt);
const dependencies = registrationNameDependencies[registrationName];
const dependencies = getEventsFromRegistraionName(registrationName);
Copy link
Contributor

Choose a reason for hiding this comment

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

Registration!

@gaearon
Copy link
Collaborator

gaearon commented Jan 8, 2018

What is the file size impact?

@jquense
Copy link
Contributor Author

jquense commented Jan 8, 2018

at the moment it's the same essentially, when gzipped, but does have the benefit of not having to add more config for each new DOM event.

Having looked through a bit more, the stumbling block for ripped more config out is the mapping between DOM event and prop name. One way to handle this is could be to build a mapping as we go in DOMFiberComponent, then map back in eventPropagators. That should mean we can remove all the explicit registration names, but still be able to handle renderer specific mappings like prefixed animation events.

I'm really not sure tho if RN is as consistent as RD on this tho, RD has little need for the level of config the event system offers.

@@ -312,7 +311,7 @@ function setInitialDOMProperties(
} else if (propKey === AUTOFOCUS) {
// We polyfill it separately on the client during commit.
// We blacklist it here rather than in the property list because we emit it in SSR.
} else if (registrationNameModules.hasOwnProperty(propKey)) {
} else if (propKey[0] === 'o' && propKey[1] === 'n') {
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be worth extracting this into a function like isEventName so it minifies better.

@nhunzaker
Copy link
Contributor

@jquense Any updates here, or desire to pick this up again?

@stale
Copy link

stale bot commented Jan 10, 2020

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 17, 2020

Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you!

@stale stale bot closed this Jan 17, 2020
@kassens kassens deleted the poc-event-registration branch November 29, 2022 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Resolution: Stale Automatically closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants