react/packages/react-native-renderer/src/ReactNativeBridgeEventPlugi...

174 lines
5.1 KiB
JavaScript
Raw Normal View History

2016-03-25 06:40:52 +08:00
/**
* Copyright (c) Facebook, Inc. and its affiliates.
2016-03-25 06:40:52 +08:00
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
2016-03-25 06:40:52 +08:00
*
* @flow
*/
import type {AnyNativeEvent} from 'legacy-events/PluginModuleType';
import type {TopLevelType} from 'legacy-events/TopLevelEventTypes';
import SyntheticEvent from 'legacy-events/SyntheticEvent';
[react-native] Use path-based imports instead of Haste for the RN renderer (#15604) * [react-native] Use path-based imports instead of Haste for the RN renderer To move React Native to standard path-based imports instead of Haste, the RN renderer that is generated from the code in this repo needs to use path-based imports as well since the generated code is vendored by RN. This commit makes it so the interface between the generated renderers and RN does not rely on Haste and instead uses a private interface explicitly defined by RN. This inverts control of the abstraction so that RN decides the internals to export rather than React deciding what to import. On RN's side, a new module named `react-native/Libraries/ReactPrivate/ReactNativePrivateInterface` explicitly exports the modules used by the renderers in this repo. (There is also a private module for InitializeCore so that we can import it just for the side effects.) On React's side, the various renderer modules access RN internals through the explicit private interface. The Rollup configuration becomes slimmer since the only external package is now `react-native`, and the individual modules are instead listed out in `ReactNativePrivateInterface`. Task description: https://github.com/facebook/react-native/issues/24770 Sister RN PR (needs to land before this one): https://github.com/facebook/react-native/pull/24782 Test Plan: Ran unit tests and Flow in this repo. Generated the renderers and manually copied them over to the RN repo. Ran the RN tests and launched the RNTester app. * Access natively defined "nativeFabricUIManager" instead of importing it Some places in the Fabric renderers access `nativeFabricUIManager` (a natively defined global) instead of importing UIManager. While this is coupling across repos that depends on the timing of events, it is necessary until we have a way to defer top-level imports to run after `nativeFabricUIManager` is defined. So for consistency we use `nativeFabricUIManager` everywhere (see the comment in https://github.com/facebook/react/pull/15604#pullrequestreview-236842223 for more context).
2019-05-23 15:23:54 +08:00
import invariant from 'shared/invariant';
// Module provided by RN:
import {ReactNativeViewConfigRegistry} from 'react-native/Libraries/ReactPrivate/ReactNativePrivateInterface';
import accumulateInto from 'legacy-events/accumulateInto';
import getListener from './ReactNativeGetListener';
import forEachAccumulated from 'legacy-events/forEachAccumulated';
import {HostComponent} from 'react-reconciler/src/ReactWorkTags';
[react-native] Use path-based imports instead of Haste for the RN renderer (#15604) * [react-native] Use path-based imports instead of Haste for the RN renderer To move React Native to standard path-based imports instead of Haste, the RN renderer that is generated from the code in this repo needs to use path-based imports as well since the generated code is vendored by RN. This commit makes it so the interface between the generated renderers and RN does not rely on Haste and instead uses a private interface explicitly defined by RN. This inverts control of the abstraction so that RN decides the internals to export rather than React deciding what to import. On RN's side, a new module named `react-native/Libraries/ReactPrivate/ReactNativePrivateInterface` explicitly exports the modules used by the renderers in this repo. (There is also a private module for InitializeCore so that we can import it just for the side effects.) On React's side, the various renderer modules access RN internals through the explicit private interface. The Rollup configuration becomes slimmer since the only external package is now `react-native`, and the individual modules are instead listed out in `ReactNativePrivateInterface`. Task description: https://github.com/facebook/react-native/issues/24770 Sister RN PR (needs to land before this one): https://github.com/facebook/react-native/pull/24782 Test Plan: Ran unit tests and Flow in this repo. Generated the renderers and manually copied them over to the RN repo. Ran the RN tests and launched the RNTester app. * Access natively defined "nativeFabricUIManager" instead of importing it Some places in the Fabric renderers access `nativeFabricUIManager` (a natively defined global) instead of importing UIManager. While this is coupling across repos that depends on the timing of events, it is necessary until we have a way to defer top-level imports to run after `nativeFabricUIManager` is defined. So for consistency we use `nativeFabricUIManager` everywhere (see the comment in https://github.com/facebook/react/pull/15604#pullrequestreview-236842223 for more context).
2019-05-23 15:23:54 +08:00
const {
customBubblingEventTypes,
customDirectEventTypes,
[react-native] Use path-based imports instead of Haste for the RN renderer (#15604) * [react-native] Use path-based imports instead of Haste for the RN renderer To move React Native to standard path-based imports instead of Haste, the RN renderer that is generated from the code in this repo needs to use path-based imports as well since the generated code is vendored by RN. This commit makes it so the interface between the generated renderers and RN does not rely on Haste and instead uses a private interface explicitly defined by RN. This inverts control of the abstraction so that RN decides the internals to export rather than React deciding what to import. On RN's side, a new module named `react-native/Libraries/ReactPrivate/ReactNativePrivateInterface` explicitly exports the modules used by the renderers in this repo. (There is also a private module for InitializeCore so that we can import it just for the side effects.) On React's side, the various renderer modules access RN internals through the explicit private interface. The Rollup configuration becomes slimmer since the only external package is now `react-native`, and the individual modules are instead listed out in `ReactNativePrivateInterface`. Task description: https://github.com/facebook/react-native/issues/24770 Sister RN PR (needs to land before this one): https://github.com/facebook/react-native/pull/24782 Test Plan: Ran unit tests and Flow in this repo. Generated the renderers and manually copied them over to the RN repo. Ran the RN tests and launched the RNTester app. * Access natively defined "nativeFabricUIManager" instead of importing it Some places in the Fabric renderers access `nativeFabricUIManager` (a natively defined global) instead of importing UIManager. While this is coupling across repos that depends on the timing of events, it is necessary until we have a way to defer top-level imports to run after `nativeFabricUIManager` is defined. So for consistency we use `nativeFabricUIManager` everywhere (see the comment in https://github.com/facebook/react/pull/15604#pullrequestreview-236842223 for more context).
2019-05-23 15:23:54 +08:00
} = ReactNativeViewConfigRegistry;
2016-03-25 06:40:52 +08:00
// Start of inline: the below functions were inlined from
// EventPropagator.js, as they deviated from ReactDOM's newer
// implementations.
function listenerAtPhase(inst, event, propagationPhase: PropagationPhases) {
const registrationName =
event.dispatchConfig.phasedRegistrationNames[propagationPhase];
return getListener(inst, registrationName);
}
function accumulateDirectionalDispatches(inst, phase, event) {
if (__DEV__) {
if (!inst) {
console.error('Dispatching inst must not be null');
}
}
const listener = listenerAtPhase(inst, event, phase);
if (listener) {
event._dispatchListeners = accumulateInto(
event._dispatchListeners,
listener,
);
event._dispatchInstances = accumulateInto(event._dispatchInstances, inst);
}
}
function getParent(inst) {
do {
inst = inst.return;
// TODO: If this is a HostRoot we might want to bail out.
// That is depending on if we want nested subtrees (layers) to bubble
// events to their parent. We could also go through parentNode on the
// host node but that wouldn't work for React Native and doesn't let us
// do the portal feature.
} while (inst && inst.tag !== HostComponent);
if (inst) {
return inst;
}
return null;
}
/**
* Simulates the traversal of a two-phase, capture/bubble event dispatch.
*/
export function traverseTwoPhase(inst: Object, fn: Function, arg: Function) {
const path = [];
while (inst) {
path.push(inst);
inst = getParent(inst);
}
let i;
for (i = path.length; i-- > 0; ) {
fn(path[i], 'captured', arg);
}
for (i = 0; i < path.length; i++) {
fn(path[i], 'bubbled', arg);
}
}
function accumulateTwoPhaseDispatchesSingle(event) {
if (event && event.dispatchConfig.phasedRegistrationNames) {
traverseTwoPhase(event._targetInst, accumulateDirectionalDispatches, event);
}
}
function accumulateTwoPhaseDispatches(events) {
forEachAccumulated(events, accumulateTwoPhaseDispatchesSingle);
}
/**
* Accumulates without regard to direction, does not look for phased
* registration names. Same as `accumulateDirectDispatchesSingle` but without
* requiring that the `dispatchMarker` be the same as the dispatched ID.
*/
function accumulateDispatches(
inst: Object,
ignoredDirection: ?boolean,
event: Object,
): void {
if (inst && event && event.dispatchConfig.registrationName) {
const registrationName = event.dispatchConfig.registrationName;
const listener = getListener(inst, registrationName);
if (listener) {
event._dispatchListeners = accumulateInto(
event._dispatchListeners,
listener,
);
event._dispatchInstances = accumulateInto(event._dispatchInstances, inst);
}
}
}
/**
* Accumulates dispatches on an `SyntheticEvent`, but only for the
* `dispatchMarker`.
* @param {SyntheticEvent} event
*/
function accumulateDirectDispatchesSingle(event: Object) {
if (event && event.dispatchConfig.registrationName) {
accumulateDispatches(event._targetInst, null, event);
}
}
function accumulateDirectDispatches(events: ?(Array<Object> | Object)) {
forEachAccumulated(events, accumulateDirectDispatchesSingle);
}
// End of inline
type PropagationPhases = 'bubbled' | 'captured';
const ReactNativeBridgeEventPlugin = {
eventTypes: {},
2016-03-25 06:40:52 +08:00
extractEvents: function(
Use browser event names for top-level event types in React DOM (#12629) * Add TopLevelEventTypes * Fix `ReactBrowserEventEmitter` * Fix EventPluginUtils * Fix TapEventPlugin * Fix ResponderEventPlugin * Update ReactDOMFiberComponent * Fix BeforeInputEventPlugin * Fix ChangeEventPlugin * Fix EnterLeaveEventPlugin * Add missing non top event type used in ChangeEventPlugin * Fix SelectEventPlugin * Fix SimpleEventPlugin * Fix outstanding Flow issues and move TopLevelEventTypes * Inline a list of all events in `ReactTestUtils` * Fix tests * Make it pretty * Fix completly unrelated typo * Don’t use map constructor because of IE11 * Update typings, revert changes to native code * Make topLevelTypes in ResponderEventPlugin injectable and create DOM and ReactNative variant * Set proper dependencies for DOMResponderEventPlugin * Prettify * Make some react dom tests no longer depend on internal API * Use factories to create top level speific generic event modules * Remove unused dependency * Revert exposed module renaming, hide store creation, and inline dependency decleration * Add Flow types to createResponderEventPlugin and its consumers * Remove unused dependency * Use opaque flow type for TopLevelType * Add missing semis * Use raw event names as top level identifer * Upgrade baylon This is required for parsing opaque flow types in our CI tests. * Clean up flow types * Revert Map changes of ReactBrowserEventEmitter * Upgrade babel-* packages Apparently local unit tests also have issues with parsing JavaScript modules that contain opaque types (not sure why I didn't notice earlier!?). * Revert Map changes of SimpleEventPlugin * Clean up ReactTestUtils * Add missing semi * Fix Flow issue * Make TopLevelType clearer * Favor for loops * Explain the new DOMTopLevelEventTypes concept * Use static injection for Responder plugin types * Remove null check and rely on flow checks * Add missing ResponderEventPlugin dependencies
2018-05-15 17:38:50 +08:00
topLevelType: TopLevelType,
targetInst: null | Object,
nativeEvent: AnyNativeEvent,
nativeEventTarget: null | Object,
2016-03-25 06:40:52 +08:00
): ?Object {
if (targetInst == null) {
// Probably a node belonging to another renderer's tree.
return null;
}
const bubbleDispatchConfig = customBubblingEventTypes[topLevelType];
const directDispatchConfig = customDirectEventTypes[topLevelType];
invariant(
bubbleDispatchConfig || directDispatchConfig,
'Unsupported top level event type "%s" dispatched',
topLevelType,
);
const event = SyntheticEvent.getPooled(
2016-03-25 06:40:52 +08:00
bubbleDispatchConfig || directDispatchConfig,
targetInst,
nativeEvent,
2017-03-14 08:05:18 +08:00
nativeEventTarget,
2016-03-25 06:40:52 +08:00
);
if (bubbleDispatchConfig) {
accumulateTwoPhaseDispatches(event);
2016-03-25 06:40:52 +08:00
} else if (directDispatchConfig) {
accumulateDirectDispatches(event);
2016-03-25 06:40:52 +08:00
} else {
return null;
}
return event;
2016-04-19 07:11:31 +08:00
},
2016-03-25 06:40:52 +08:00
};
export default ReactNativeBridgeEventPlugin;