[RN] Consolidate eventTypes registry with view configs

[sebmarkbage]

We already have one stateful module that contains all the view config.
We might as well store the event types there too. That way the shared
state is compartmentalized (and I can move it out in a follow up PR).

The view config registry also already has an appropriate place to call
processEventTypes so now we no longer have to do it in RN.

Will follow up with a PR to RN to remove that call.

[sebmarkbage]

This is what lets us avoid exposing ReactNativeBridgeEventPlugin.

[bvaughn]

I think this should be okay, so long as requireNativeComponent is updated before it lands.

[bvaughn]

We can also delete the forwarding scripts/rollup/shims/react-native/ReactNativeBridgeEventPlugin.js now?

[bvaughn]

Should we just get rid of the ReactNativeBridgeEventPlugin entirely now and just move extractEvents over into the view config registry as well?

[sebmarkbage]

Good catch on the shim. I'll delete it.

[sebmarkbage]

extractEvents is part of the event plugin mechanism and is conceptually different.

The registry is just a store of configurable fields and doesn’t change unless we change how RN talks to native.

Extract events goes into the synthetic event system, plugin order and that whole system. A system that we know we’ll want to change and when we do change it, it’ll affect everything in the React repo and nothing in the RN repo so it’s coupled to React.

[bvaughn]

Gotcha.

[janicduplessis]

@sebmarkbage @bvaughn We're using ReactNativeBridgeEventPlugin.processEventTypes in react-native-gesture-handler to register a custom event type for views (see here and here). There isn't a particular native component associated with these events so we cannot use requireNativeComponent (we used to register a dummy native component as a hack but now events are registered lazily so it doesn't work).

Is there an alternative I'm not seeing or could we bring this back as public'ish API (as public as importing react-native/Libraries/Renderer/shims/ReactNativeBridgeEventPlugin gets 😄)?

[gaearon]

This is a bit ironic because shims was added as a temporary measure to expose private APIs to RN itself. Didn’t even occur to me third-party libs would attempt to import those 😛

[janicduplessis]

Yea it is a very low level library and RN doesn't export anything to be able to do that so some creativity was needed. A solution that could also work is to expose a root HOC that renders a native component that registers the view types but it seems like quite a bit of overhead just to register the events (both the extra API in react-native-gesture-handler and the runtime overhead of the extra view).

If we decide to bring this back we could add it as extra RN public API so it is less likely to break in the future, although I'm not familiar enough with this API to know how stable it is. Something like an undocumented UNSTABLE_registerExtraEventType might be good.