@nomadtechie I think there’s a few questions here that we need to split apart.
1. Is an event system useful (as opposed to just attaching events on nodes)
2. Does it have to wrap native event objects into custom ones
3. Are React's event polyfills still relevant
1. Is an event system useful (as opposed to just attaching events on nodes)
2. Does it have to wrap native event objects into custom ones
3. Are React's event polyfills still relevant
@nomadtechie The answer to (1) is yes IMO. Event system uses delegation — i.e. instead of a listener per node, we attach it at the top. This is useful for features we care about (like ability to “record” and “replay” events after hydration). Less work on mount. Solves some edge cases too.
@nomadtechie The answer to (2) is probably no and we can probably use native events there. We’re already removing pooling in 17 so they’re very close. There’s some normalization we still do but it’s probably not as important these days or could be polyfilled separately from React.
@nomadtechie The answer to (3) is that we’re lagging behind. Our fixes are mostly around IE compat and such, which isn’t as important these days. But we fail to polyfill other cases that are important. So we can probably drop some of that in later releases.
@nomadtechie The answer to “why not opt-in” is because it’s a global concern. Like if you were to change the event API, that would affect every component. Global options like this are a huge strain on the ecosystem because none of the npm components would know which kind of event they’d get.
@nomadtechie So overall I think the goal is to get a lot closer to native events (and reduce the polyfills) but keep the delegation mechanism.
