Summary:
`getSize` should resolve with an array of `[width, height]` but this mock resolves with `{ width, height }`.
It should be `ReadOnlyArray<number>` instead of `{width: number, height: number}`
The native image loader call is [here](https://github.com/facebook/react-native/blob/main/Libraries/Image/NativeImageLoaderIOS.js#L18):
```js
+getSize: (uri: string) => Promise<$ReadOnlyArray<number>>;
```
but in the [jest setup file](https://github.com/facebook/react-native/blob/main/jest/setup.js):
```js
getSize: jest.fn(url => Promise.resolve({width: 320, height: 240})),
```
My tests were failing on `Image.getSize()` - `TypeError: Invalid attempt to destructure non-iterable instance.`
I managed to trace this down to this object being returned by the Jest mock - looks like it's returning a size object instead of a dimensions array.
## Workaround
If you are hitting this issue, you can work around this mock by using:
```js
ReactNative.NativeModules.ImageLoader.getSize = jest.fn((_) => Promise.resolve([320, 240]));
```
## Changelog
[JavaScript] [Changed]: Changed the mocked return value of `ImageLoader.getSize` to be `[320, 240]` instead of `{ width: 320, height: 240 }`
Pull Request resolved: https://github.com/facebook/react-native/pull/34653
Test Plan: TBD? I think a test with `Image.getSize(path)` will cover it. That's where I hit the error with the ios-specific imageLoader's getSize method.
Reviewed By: robhogan
Differential Revision: D39413522
Pulled By: NickGerleman
fbshipit-source-id: 7f18d7acde0cf94da0b4aec8fe2d0cad3fb0cc55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34659
We've used this Promise polyfill in Jest setup since at least 2015 ([`3ff3987`](3ff39870ce)), when native Promise implementations were either non-existent or new and unstable. We no longer need it.
It causes issues with "modern" timers in Jest, as documented in:
- https://github.com/facebook/react-native/issues/29303
- https://github.com/facebook/jest/issues/10221
It can also obscure real issues due to its default silent handling of uncaught rejections, eg: D39418412.
Changelog:
[General][Changed] - Don't polyfill Promise in Jest setup
Reviewed By: huntie
Differential Revision: D39417597
fbshipit-source-id: d12433ed66c06a402632c2e1d525aad112ef9b0c
Summary:
The removeEventListener method has been removed from AccessibilityInfo and Linking in this PR: https://github.com/facebook/react-native/issues/33580, so I believe we can remove it from the mocks.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Removed] - Remove removeEventListener from AccessibilityInfo and Linking mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/34260
Test Plan: I executed jest and everything is still green.
Reviewed By: dmitryrykun
Differential Revision: D38198653
Pulled By: GijsWeterings
fbshipit-source-id: 72d10ca54cd505d7c76e7531c9df718b1a9b9ed1
Summary:
Changelog:
[Internal] Rename AccessibilityInfo.sendAccessibilityEvent_unstable to sendAccessibilityEvent
In Fabric, we want people to use `AccessibilityInfo.sendAccessibilityEvent` instead of `UIManager.sendAccessibilityEvent` for Android. The API is not unstable. There is a test in [AccessibilityExample.js](c940eb0c49/packages/rn-tester/js/examples/Accessibility/AccessibilityExample.js (L959)) in RNTester to confirm that it works.
A search for [`AccessibilityInfo.sendAccessibilityEvent_unstable` in Github](https://github.com/search?q=AccessibilityInfo.sendAccessibilityEvent_unstable&type=Code) shows that it's not being used yet, which makes sense because it's an Fabric API. Therefore it's safe to rename it.
Reviewed By: sammy-SC
Differential Revision: D37901006
fbshipit-source-id: 73f35b09ca8f9337f4d66a431f0a3f815da38249
Summary:
I wrote a test for a vibration feature in a react native app by importing the `Vibration` module and using `jest.spyOn(Vibration, 'vibrate')`.
I had the following error:
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'Vibration' could not be found. Verify that a module by this name is registered in the native binary.
```
That lead me to look for (and not find) a mock for the `Vibration` module in the code.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Add Jest mock for Vibration module
Pull Request resolved: https://github.com/facebook/react-native/pull/30643
Test Plan:
I would be glad to provide a test plan for this, but as it is part of testing I don't really know how to do so.
Any suggestion or help is welcome!
Reviewed By: yungsters
Differential Revision: D36097003
Pulled By: cortinico
fbshipit-source-id: 58683120da34f40e142a44c4bef8a5fced04bac2
Summary:
The Modal's mock always render its children (whether it is visible or not), whereas in reality the Modal renders `null` when the Modal is not visible.
This causes troubles when trying to test whether the Modal is visible or not. Instead of testing if the children are rendered (using getByText from React Native Testing Library for instance), we are forced to test the value of the visible prop directly (see https://github.com/callstack/react-native-testing-library/issues/508 and https://github.com/callstack/react-native-testing-library/issues/659).
This is not ideal because we are forced to test implementation detail and can't test from the user perspective. I also believe the mock should be closest as possible from reality.
I had 2 options:
1. Rendering the Modal without its children
2. Not rendering the Modal at all
The latter has the advantage of being closer to the reality, but I chose the former to still be able to test the Modal through the visible prop, so there is no breaking change (only snapshots update will be required).
## Changelog
[General] [Changed] - Update Modal's mock to not render its children when it is not visible
Pull Request resolved: https://github.com/facebook/react-native/pull/32346
Test Plan:
I added a test case when visible is false, then updated the mock so the children are not rendered. The before / after is here:
![image](https://user-images.githubusercontent.com/17070498/136256142-a351d002-8b77-490a-ba65-1e8ad0d6eb55.png)
Reviewed By: yungsters
Differential Revision: D31445964
Pulled By: lunaleaps
fbshipit-source-id: 08501921455728cde6befd0103016c95074cc1df
Summary:
`window` exists in the React Native runtime, but not inside the test environment. Many libraries use `typeof window === 'undefined'` to check if code is running in SSR. Because of the difference in the real environment and test environment, tests can behave different than the real app, which is an unwanted behavior.
## Background
I'm using https://github.com/tannerlinsley/react-query in my React Native Project, which works really well. When writing tests, they wouldn't work: jest started and then seemingly did nothing. While debugging I noticed the render was stuck in an infinite loop. Then I noticed the following line inside `react-query`:
```js
const isServer = typeof window === 'undefined'
```
I didn't know that the React Native runtime has a global `window`, and thought it's a bug inside react-query. But it does have a `window`, which is not defined inside the test environment.
The infinite loop was caused by react-query thinking it is running on the server, which doesn't fetch any data. If the react-query hook mounts, it re-executes because then it should be mounted inside the client. But `isServer` was still `true`. This repeats forever.
## Changelog
[General] [Fixed] - Fix `window` not existing in jest setup
Pull Request resolved: https://github.com/facebook/react-native/pull/28067
Test Plan: Are there tests to check if the test environment is setup correctly? �
Reviewed By: yungsters
Differential Revision: D30317021
Pulled By: charlesbdudley
fbshipit-source-id: 837ed952833ef8e70c5132c9b4152b0e0f28b4dd
Summary:
This diff and stack migratest Migrate UIManager.getViewManagerConfig -> UIManager.hasViewManagerConfig
This is necessary to avoid initializing UIManagerModule to detect if a component is registered into the native platform
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D27983716
fbshipit-source-id: 504180d8883959835e736f8081610b8c49810803
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
D27682424 (ea1ff374de) updated how animated node batches are executed in Fabric. On Paper, these batches were controlled by native module in some places (batch was executed ~every 2 frames), but some animations were switching animation batching control to JS globally there as well.
This change updates two things:
- If batching is controlled by native, it makes sure batches are calculated correctly.
- At the same time, this change switches control for animation node batching to JS, aligning it with Fabric.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27939659
fbshipit-source-id: d6251bce2a303a4a007dc10297edc0175cc4b348
Summary:
Unifies the platform-specific implementations of `AccessibilityInfo` to simplifying checking Flow types and making changes to the module.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D27578847
fbshipit-source-id: 84dc274a66acd22fc6f1dd2773a4e4630761e17d
Summary:
This diff is a revert of the stack D27276533. the native fix will be included as part of another diff
changelog: [internal] internal
Reviewed By: JoshuaGross, ShikaSD
Differential Revision: D27332513
fbshipit-source-id: 203051ea8fec3f508d79c329c9b61399fbbc3d1b
Summary:
This diff and stack migratest Migrate UIManager.getViewManagerConfig -> UIManager.hasViewManagerConfig
This is necessary to avoid initializing UIManagerModule to detect if a component is registered into the native platform
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27276526
fbshipit-source-id: f3cc0218506ea2066a0d85f956b15a0e40f2e072
Summary:
Updates the AppState Jest mock to correspond to recent API changes.
Changelog:
[General][Fixed] - Updated AppState Jest mock to match new public API
Reviewed By: yungsters
Differential Revision: D26295371
fbshipit-source-id: e6e39f23d9100f0eacf257f45d509c5364dcb28d
Summary:
`sendAccessibilityEvent_unstable` is a cross-platform, Fabric/non-Fabric replacement for previous APIs (which went through UIManager directly on Android, and a native module on iOS).
Changelog: [Added] sendAccessibilityEvent_unstable API in AccessibilityInfo and sendAccessibilityEvent in React renderer
Reviewed By: kacieb
Differential Revision: D25821052
fbshipit-source-id: 03f7a9878c95e8395f9102b3e596bfc9f03730e0
Summary:
This diff removes the call to UIManager.getViewManagerConfig into the deprecatedPropType method when static view configs are enabled
This was necessary to avoid innecessary calls to UIManager.getViewManagerConfig and to avoid loading UIManagerModule classes when static view configs are enabled
changelog: [internal] internal
Reviewed By: fkgozali, yungsters
Differential Revision: D26040855
fbshipit-source-id: 82cad9f4abe9898e781fd989ebaa03497dad926b
Summary:
Creates `NativeComponentRegistry.getWithFallback_DEPRECATED`. This is deprecated from inception because it exists only to support a pattern that should not be necessary.
For any given `NativeX` component, the JavaScript module that calls `NativeComponentRegistry.get('NativeX', …)` should only exist in the JavaScript bundle if the native binary actually supports that native component.
But in today's transitional state of the world, there are JavaScript modules that use `UIManager.getViewManagerConfig('NativeX')` as a means of feature detection.
The purpose of `NativeComponentRegistry.getWithFallback_DEPRECATED` is to bridge this transitional gap. Component should migrate toward initializing the `NativeComponentRegistry` with a runtime configuration provider that enumerates all supported native components. If the native component is not supported, it should return null.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25109988
fbshipit-source-id: 76f7077904594ca63495d8338905c43712ea02e0
Summary:
Creates `NativeComponentRegistry` which makes native component initialization more declarative and configurable through an optionally configurable provider.
The next diff converts `ScrollView` to use this new abstraction as a demonstration. The plan would be to use this to replace all current manual call sites of `registerGeneratedViewConfig`, and then the ones generated via the Babel plugin.
Migrating to this will not change any production behavior, but it will enable verification of `ViewConfig` in development.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25084468
fbshipit-source-id: 9c758ddc279bf937a401a868a066907a94098f37
Summary:
Replaces `fbjs/performanceNow` call sites in React Native with `performance.now`.
We did not originally polyfill this in `InitializeCore`, but now we do (and back it with a proper `nativePerformanceNow` implementation). Also, added the missing polyfill to our Jest setup.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22445948
fbshipit-source-id: dcfd9867c050617f6e2a3d0a1eb6f48a44771dda
Summary:
Provide a mocked `DevSettings` implementation for jest.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Add mock for `DevSettings` to jest preset
Pull Request resolved: https://github.com/facebook/react-native/pull/29223
Test Plan: None
Reviewed By: cpojer
Differential Revision: D22279962
Pulled By: TheSavior
fbshipit-source-id: 667cecb0a558a4267564702ee9d30380756bdd92
Summary:
Have ScrollView use forwardRef so that the host component methods like `measure` and `measureLayout` are available without having to call `getNativeScrollRef`. Instead, you can use `<ScrollView ref={myRef} />` and directly call all methods of ScrollView and host components on `myRef`.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getNativeScrollRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView ref={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
myRef.current.measureLayout();
// Additionally, myRef still has access to ScrollView methods
myRef.current.scrollTo(...);
```
Changes:
* Added deprecation warnings to ScrollView methods `getNativeScrollRef`, `getScrollableNode`, and `getScrollResponder`
* Added the forwardRef call to create `ForwardedScrollView` - this takes in `ref` and passes it into the class ScrollView as `scrollViewRef`.
* Forwarded the ref to the native scroll view using `setAndForwardRef`.
* Added statics onto `ForwardedScrollView` so that `ScrollView.Context` can still be accessed.
* Added type `ScrollViewImperativeMethods`, which lists the public methods of ScrollView.
* Converted all public methods of ScrollView to arrow functions. This is because they need to be bound to the forwarded ref.
* Bound all public methods of ScrollView to the forwarded ref in the `setAndForwardRef` call.
* Flow typed the final output (ForwardedScrollView) as an abstract component that takes in the props of the `ScrollView` class, and has all methods of both the inner host component (`measure`, `measureLayout`, etc) and the public methods (`scrollTo`, etc).
Changes to mockScrollView:
* Changed mockScrollView to be able to mock the function component instead of a class component
* Updated necessary tests
Changelog:
[General] [Changed] - Make ScrollView use forwardRef
Reviewed By: TheSavior
Differential Revision: D19304480
fbshipit-source-id: 6c359897526d9d5ac6bc6ab6d5f9d82bfc0d8af4
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
This diff fixes an issue where errors in LogBox during tests would cause the tests to crash.
The crash is due to the NativeExceptionsManager module not being mocked (as all native module need to be in tests). The fix is to properly mock the NativeExceptionManger.
This fix exposed an infinite loop issue where failures in LogBox will be logged to the ExceptionManager, which logs to the console, which logs to LogBox, creating a loop. This diff also fixes that look by moving the LogBox internal error check to the top of the monkey patched console methods.
Changelog: [Internal]
Differential Revision: D20428590
fbshipit-source-id: 7289a480c99ba8dee67772178b7629afb40b330a
Summary:
This PR adds the `isFocused` method to the mock of the TextInput component. My understanding some of the latest changes on the TextInput to make it use a forwardRef change the way this method is mock giving an error when trying to use in on a mock.
The change suggested here fixes the issue.
## Changelog
[JavaScript] [Fixed] - Fix the mock for TextInput to support the `isFocused` method
Pull Request resolved: https://github.com/facebook/react-native/pull/28332
Reviewed By: cpojer
Differential Revision: D20538044
Pulled By: TheSavior
fbshipit-source-id: be734af105ab62ffdf9ed4017bd70845e207f8cd
Summary:
`AccessibilityInfo.isScreenReaderEnabled().then()` fails by default in tests because that function is mocked and it doesn't return a promise (the default return value is `undefined`). Returning `Promise.resolve(false)` is a good default in this case so it doesn't break any code relying on it.
Changelog: [General] [Fixed] - Fix `AccessibilityInfo.isScreenReaderEnabled` mock in Jest setup
Reviewed By: lunaleaps, motiz88
Differential Revision: D19972921
fbshipit-source-id: 3c8498d5aeeac54d1f5cf333ae39658e22c180a1
Summary:
This class is no longer used by the core and thus can be removed.
It isn't exposed as part of our public API so this is technically not a breaking change, although it may still cause people trouble if they are reaching into internals. It is expected that people will use forwardRef instead of this class.
I will follow up this diff with a removal from the ReactNativeRenderer as well.
Changelog:
[Internal] Remove ReactNative.NativeComponent from React Native
Reviewed By: JoshuaGross
Differential Revision: D19888400
fbshipit-source-id: 78da51e6c0edf9d8706395d376c3bfe75dabda03
Summary:
TextInput now acts as a host component and can be passed directly to our new APIs that require a host component. Callsites no longer need to call
```
inputRef.getNativeRef()
```
We mutate the ref to the host component adding the imperative methods of the TextInput so you can still call `inputRef.clear` and `inputRef.isFocused`.
Changelog:
[General][Changed] TextInput now uses `forwardRef` allowing it to be used directly by new APIs requiring a host component.
Reviewed By: yungsters
Differential Revision: D18458408
fbshipit-source-id: 1f149fd575210d702fa0fdf3d05bb2162436a773
Summary:
Deletes `__skipSetNativeProps_FOR_TESTS_ONLY` in favor of a `process.env_NODE_ENV` check (which will be eliminated from production builds).
Changelog:
[General] [Removed] Removed `__skipSetNativeProps_FOR_TESTS_ONLY` from Animated components.
Reviewed By: TheSavior
Differential Revision: D18289739
fbshipit-source-id: 7c1f7a29f2b88821d358227a07eec778773e418a
Summary:
Simplifies `Animated` by removing `defaultProps` in favor of composition and a more isolated fix for scroll components.
Changelog:
[Breaking] Removed second defaultProps argument from createAnimatedComponent.
Reviewed By: TheSavior
Differential Revision: D18289648
fbshipit-source-id: 4e91c34297c3231f2bf691da74a7a624ca0b4f29
Summary:
Since react-native 0.58, I encountered some issues about snapshot with animated components. I opened an issue here : https://github.com/facebook/react-native/issues/25653
After hours of debugging, I finally found the problem:
In RN 0.57, an Animated View was created like this :
`View: AnimatedImplementation.createAnimatedComponent(View)`
And `AnimatedImplementation` was mock like this :
```
mock('../Libraries/Animated/src/AnimatedImplementation', () => {
const AnimatedImplementation = jest.requireActual('../Libraries/Animated/src/AnimatedImplementation');
const oldCreate = AnimatedImplementation.createAnimatedComponent;
AnimatedImplementation.createAnimatedComponent = function(
Component,
defaultProps,
) {
const Wrapped = oldCreate(Component, defaultProps);
Wrapped.__skipSetNativeProps_FOR_TESTS_ONLY = true;
return Wrapped;
};
return AnimatedImplementation;
})
```
So thanks to this mock, the animated component had a props `__skipSetNativeProps_FOR_TESTS_ONLY` set to `true` and this was used to forceUpdate the component
```
if (AnimatedComponent.__skipSetNativeProps_FOR_TESTS_ONLY || typeof this._component.setNativeProps !== 'function') {
this.forceUpdate();
}
```
But since RN 0.58, the way we create an animated component as changed into :
```
const View = require('View');
const createAnimatedComponent = require('createAnimatedComponent');
module.exports = createAnimatedComponent(View);
```
As you can see, we directly use `createAnimatedComponent`, we don't use it through `AnimatedComponent` like before.
This caused the animated component had not anymore the props `__skipSetNativeProps_FOR_TESTS_ONLY`, so the component doesn't forceUpdate during the animation and breaks the snapshot.
Mocking `createAnimatedComponent` fix the problem
## Changelog
[General] [Fixed] - Mock createAnimatedComponent to fix snapshot with animated component
Pull Request resolved: https://github.com/facebook/react-native/pull/26109
Test Plan: See the issue
Differential Revision: D17155134
Pulled By: cpojer
fbshipit-source-id: 892efc7e820e3db4eb670ddec8fcbf7702bb69bf
Summary:
This function was used by Touchable*. It was removed from the Touchables in D6494579 in 2017. The only remaining callsite was ImageBackground which is attaching a ref directly to the View so we know it is a native component.
This is needed for some setNativeProps cleanup
Reviewed By: sahrens
Differential Revision: D16796973
fbshipit-source-id: 19379094b3b91920efac4bf1969fc22d4b80bcc6
Summary: There is a `setUpDeveloperTools.js` and a `setupDevtools.js` files. While they do set up different devtools it is very confusing to have these two files. This diff inlines one in the other which should bring more clarity.
Reviewed By: gaearon
Differential Revision: D16121236
fbshipit-source-id: 45641c7af9639ede6dc237ac53b763cd804a05c2
Summary:
View needed this wrapper to add a dev time warning about text children. Text children became supported and this warning was removed in https://github.com/facebook/react-native/pull/23195
This check is no longer necessary and we can reduce the overhead and improve the performance of View by removing this.
Reviewed By: rickhanlonii
Differential Revision: D15914658
fbshipit-source-id: 6456a9cb356245fa8104036b2948aa5c5bf39e0f
Summary:
Using Animated components like View and Image do not get created with __skipSetNativeProps_FOR_TESTS_ONLY = true since they get created before the jest mock can be applied to createAnimatedComponent. For these components mock getters to create versions that properly skip set native props.
Jest tests that render these components get warnings the setNativeProps gets called even though using a testRenderer this should not happen.
## Changelog
[Javascript] [Fixed] - Define Animated Components for react-native/jest/setup that properly skip setNativeProps
Pull Request resolved: https://github.com/facebook/react-native/pull/25108
Differential Revision: D15779434
Pulled By: cpojer
fbshipit-source-id: f39e21ed8e71c2c155297c791d3bf573909896d6
Summary:
This commit more clearly defines the mocks RN sets up and uses paths instead of Haste names to define the mocks. The Jest setup script defined mocks for native modules (Obj-C, Java) and mocks for JS modules in the same data structure. This meant that some non-native modules (that is, JS modules) were in the `mockNativeModules` map -- this commit splits them out and mocks them in typical `jest.mock` fashion.
Additionally, the setup script used to mock the modules using the Haste names. As one of the steps toward migrating to standard path-based imports, the setup script now mocks JS modules using paths (native modules don't need a Haste name nor path since they are just entries in `NativeModules`). This gets us closer to being able to remove `hasteImpl`. (Tracking in https://github.com/facebook/react-native/issues/24772.)
Also, this commit removes mocks that are not referenced anywhere in the RN and React repositories (grepped for the names and found no entries outside of the Jest setup scripts).
## Changelog
[General] [Changed] - Explicitly separate mocked native modules from mocked JS modules
Pull Request resolved: https://github.com/facebook/react-native/pull/24809
Differential Revision: D15316882
Pulled By: cpojer
fbshipit-source-id: 039e4e320121bea9580196fe0a091b8b1e8b41bf