Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Several desktop forks (`react-native-macos`, `react-native-windows`, `react-native-web`) support mouse events, and while the stock Pressable component has the ability to support mouse events, it seems we aren't forwarding some props properly from Pressable -> Pressability.
Pressability will calculate onMouseEnter / onMouseLeave event handlers based on the `onHoverIn/onHoverOut` callbacks passed into PressabilityConfig.
https://github.com/facebook/react-native/blob/ad0d4534a751ed05f84ff971714c8f7a4d1deb3a/Libraries/Pressability/Pressability.js#L552
However, Pressable does not pass take in onHoverIn/onHoverOut props to pass to PressabilityConfig, so we can't take advantage of this functionality. This change should simply address that by passing the props through.
## 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] - Pressabel not passing hover props and event handlers to PressabilityConfig
Pull Request resolved: https://github.com/facebook/react-native/pull/32405
Test Plan: I fixed a similar issue in `react-native-macos` that I am now trying to contribute back upstream. https://github.com/microsoft/react-native-macos/pull/855
Reviewed By: yungsters
Differential Revision: D31667737
Pulled By: sota000
fbshipit-source-id: f0bbe48302703bb2c45280d2afeec8d7a4586b6a
Summary:
As per the XMLHttpRequest specification [1], getAllResponseHeaders() should return a string of headers with lowercased names and sorted by their uppercase representation, with each header ending with '\r\n'.
[1] https://xhr.spec.whatwg.org/#the-getallresponseheaders()-method
## Changelog
[General] [Changed] XMLHttpRequest.getAllResponseHeaders() now returns headers with names lowercased and sorted in ascending order, as per specification
Pull Request resolved: https://github.com/facebook/react-native/pull/32363
Test Plan:
Test derived from Web Platform Test repository:
https://github.com/web-platform-tests/wpt/tree/master/xhr
Reviewed By: yungsters
Differential Revision: D31626217
Pulled By: sota000
fbshipit-source-id: 299d005facbe1c15b8cda5eed6750db75addca80
Summary:
Single and composite animations were handled inconsistently in AnimatedMock. Also added a guard to prevent callbacks from triggering additional animations, since we had a test-scenario that did exactly that.
Changelog:
[General][Fixed] - Composite animations will now be ran immediately when the app is in testing mode
Reviewed By: yungsters
Differential Revision: D31826967
fbshipit-source-id: a6416b42e227fe79f5c3a55a9c51beb8451874f8
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
Changelog: [internal]
This change had to be reverted because it caused some issues internally at Facebook. After we solved those we re-applied the changes but this also has issues in OSS apps. Specifically, the option in Metro to inject modules to execute before the EntryPoint (in this case `InitializeCore`) doesn't work if those modules aren't part of the bundle in the first place.
This reverts again so we can think about a long-term solution for this.
Original commit changeset: ba145a30ead5
Reviewed By: ShikaSD
Differential Revision: D31825736
fbshipit-source-id: 393b3d5d2a726951a9ac386dc2b1c19ef4a916a5
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
Creates a new `StaticViewConfigValidator` module that does strict, bidirectional validation. This is notably different from `verifyComponentAttributeEquivalence`, which is undirectional validation.
This will enforce that two configs are equivalent so we can start addressing the inconsistencies (especially per platform). It also improves upon the reporting format by providing more details about the invalidations.
It is hidden behind a `strict` runtime configuration parameter.
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29024229
fbshipit-source-id: 10271945e089183f505205bd41de5e01faea7568
Summary:
this little PR remove `accesibilityStates` config in validAttributes, like comment says it can be removed after next release.
## Changelog
[General][Removed] - `accessibilityStates` no longer passed through to RCTView.
Pull Request resolved: https://github.com/facebook/react-native/pull/29656
Reviewed By: philIip
Differential Revision: D31732866
Pulled By: yungsters
fbshipit-source-id: 83b6eb223e76537a09c13ccdb382317421ab4585
Summary:
The documentation of back easing contains a old link that
is now stale. I'm updating it to link to https://easings.net/#easeInBack
Fixes https://github.com/facebook/react-native/issues/32419
Changelog:
[Android] [Fixed] - Fixes documentation for back Easing animation
Reviewed By: hramos
Differential Revision: D31728560
fbshipit-source-id: 99f7aa60d3748af5429b4ae1aa6cbd79326c5fe6
Summary:
While reworking our media picker, I ended up replacing the RNFetchBlob library to use `fetch()`, leveraging React Native's file resolver (especially to interpret `photos://` URI paths).
The migration process was pretty straightforward, however I kept getting RCTConvert errors when calling `fetch` with a `PUT` method and a blob body:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
+[RCTConvert NSString:]
RCTConvert.m:59
-[RCTBlobManager handleNetworkingRequest:]
-[RCTNetworking processDataForHTTPQuery:callback:]
-[RCTNetworking buildRequest:completionBlock:]
-[RCTNetworking sendRequest:callback:]
__invoking___
-[NSInvocation invoke]
-[NSInvocation invokeWithTarget:]
-[RCTModuleMethod invokeWithBridge:module:arguments:]
Test Plan:
I'll put my `fetch` snippet here. This is using a third-party library in order to get a signed URL, but it is otherwise pretty straightforward.
This snippet would trigger an error before the changes introduced by this PR.
```js
// Setup (specific to third-party lib)
const key = `file/path/in/bucket`
const params = {
Key: key,
Bucket: 'my.awesome.bucket',
}
const s3url = await s3.getSignedUrl('putObject', params)
// Letting RN handle how to retrieve a platform-specific resource URI
const localFetch = await fetch(localPath)
// Getting the blob to upload as octet-stream
const blob = await localFetch.blob()
// Actually uploading
await fetch(s3url, {
method: 'PUT',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/octet-stream',
},
body: blob,
})
```
Reviewed By: RSNara
Differential Revision: D31625636
Pulled By: sota000
fbshipit-source-id: a7770018bc3ff2f41321b1bd26ec145b86b18784
Summary:
https://reactnative.dev/docs/view.html doesn't work, this diff replaces the url for the new link
[Changelog]
[General][Fixed] - Updated documentation link in `View`.
Reviewed By: yungsters
Differential Revision: D31519836
fbshipit-source-id: c93feee4652caf4ef8390a047599149fc547db48
Summary: Changelog: [Internal] - Change accessibilityValue.text type to allow for Stringish type
Reviewed By: yungsters
Differential Revision: D31577860
fbshipit-source-id: af12505794037a68850a16ce139359e2f8a879e4
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This module is imported by all flavors of the React Native renderers (dev/prod, Fabric/Paper, etc.), which itself imports `InitializeCore`. This is effectively a no-op in most React Native apps because Metro adds it as a module to execute before the entrypoint of the bundle.
This import would be harmless if all React Native apps included all polyfills and globals, but some of them don't want to include everything and instead of importing `InitializeCore` they import individual setup functions (like `setupXhr`). Having this automatic import in the renderer defeats that purpose (most importantly for app size), so we should remove it.
The main motivation for this change is to increase the number (and spec-compliance) of Web APIs that are supported out of the box without adding that cost to apps that choose not to use some of them (see https://github.com/facebook/react-native/pull/30188#issuecomment-929352747).
Changelog: [General][Removed] Breaking: Removed initialization of React Native polyfills and global variables from React renderers.
Note: this will only be a breaking change for apps not using the React Native CLI, Expo nor have a Metro configuration that executes `InitializeCore` automatically before the bundle EntryPoint.
Reviewed By: yungsters
Differential Revision: D31472153
fbshipit-source-id: 92eb113c83f77dbe414869fbce152a22f3617dcb
Summary:
We are defining an alias for the global variable in React Native called `GLOBAL`, which is not used at all at Facebook and it doesn't seem it's used externally either. This alias is not standard nor common in the JS ecosystem, so we can just remove it to reduce the pollution of the global scope.
Changelog: [General][Removed] - Removed unnecessary global variable `GLOBAL`.
Reviewed By: yungsters
Differential Revision: D31472154
fbshipit-source-id: 127c3264848b638f85fb2e39e17ed2006372d2dd
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:
Reviewed By: yungsters
Differential Revision: D31445964
Pulled By: lunaleaps
fbshipit-source-id: 08501921455728cde6befd0103016c95074cc1df
Summary:
We noticed that by default when the RootView / ReactView calls runApplication, we're logging at an info level any props ("params") passed to that component. In our case, one of these props was sensitive in nature, causing the value to leak out in logs for our release builds. This is especially problematic on Android where device logs can be accessed by any app which requests that permission.
This is probably more of a concern for brownfield react-native apps, but it seems worthwhile locking this down in non-dev builds.
## 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] [Security] - Avoiding logging root view params outside of dev / debug mode builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31522
Test Plan: * build app in release mode on Android and verified I could not see: `Running "my app" with { sensitive: 'thing' }` in logcat in Android Studio with a tethered device
Reviewed By: yungsters
Differential Revision: D31064902
Pulled By: charlesbdudley
fbshipit-source-id: 8b10a46d92a9ec44243dd74384299087260c7d83
Summary:
Implement par of the discussion https://github.com/react-native-community/discussions-and-proposals/discussions/411, except the `.nvmrc` part, this includes:
- Setting `.ruby-version` in the main project and also `template/`
- Fixing the CocoaPods version with a project-level `Gemfile` and also `template/Gemfile`
- Using all `pod` executions from `bundle exec pod`, using the determined version
- Script to manage and update the ruby version
## Changelog
[iOS] [Added] - Gemfile with CocoaPods 1.11 and ruby-version (2.7.4)
Pull Request resolved: https://github.com/facebook/react-native/pull/32303
Test Plan: Build for iOS and run all CircleCI tests to see if nothing changed
Reviewed By: RSNara
Differential Revision: D31344686
Pulled By: fkgozali
fbshipit-source-id: 25c63131ca9b16d3cf6341019548e0d63bdcaefe
Summary:
Pressability previously was filtering which events get forwarded through the PerformanceEventEmitter, but this causes issues for native telemetry systems which won't know which events Pressability has skipped (or why).
Also, the "delay ms" no longer has any meaning because the native timestamps and Date.now() have a different time-basis entirely.
Changelog: [Internal]
Differential Revision: D31251300
fbshipit-source-id: f097047ac150e8dddb0f3857d9f375bae2318681
Summary:
When we were iterating on the Fabric renderer, animated components went through some iteration to ensure that animated shadow nodes were not flattened away. At the time, `collapsable` was not supported on iOS, even in Fabric, because the legacy renderer would not publish the `collapsable` prop on the view config.
This has since been fixed and `collapsable` is supported on both Android and iOS. We no longer need the `nativeID` workaround to prevent view flattening.
For use cases of the JavaScript driver and legacy renderers, this change will cause views which used to be flattened to no longer be flattened. This seems like an appropriate change considering the direction that we are moving (in which everything is eventually transitioned to using the Fabric renderer).
Changelog:
[Android][Changed] - Native views backing Animated.View (w/ JavaScript-driven animations) will no longer be flattened; this should be a transparent change.
Reviewed By: lunaleaps, mdvacca
Differential Revision: D31223031
fbshipit-source-id: 48dc63471eef406f4c215bfea0b3ef82a05d4b24
Summary:
Fix Image defaultSource not showing on iOS.
This bug was introduced somewhere between RN 0.63 and 0.65. On iOS, defaultSource does not show while the image is being downloaded, only if it fails or there's no internet.
## 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
-->
[iOS] [Fixed] - Fix Image defaultSource not showing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32172
Test Plan: Ran both debug and release builds on an iPhone 12 pro (iOS 14.6)
Reviewed By: sammy-SC
Differential Revision: D30822805
Pulled By: lunaleaps
fbshipit-source-id: c4ef18723a8311ef3be1d7ae25ff3c205e8fff62
Summary:
Fixed typo in Share component docs
## 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
-->
[Internal] [Fixed] - Fix typo in Share component docs
Pull Request resolved: https://github.com/facebook/react-native/pull/31295
Test Plan: N/A
Reviewed By: yungsters
Differential Revision: D31152173
Pulled By: charlesbdudley
fbshipit-source-id: 831252f24876986fd053ff5e9875fef1132fa957
Summary:
Original commit changeset: 9ccfb4b6d477 / D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195)
The diff caused a redbox/error in some products. Reverting now and will try it again.
Changelog: Backing out PR: 31402
Differential Revision: D31238961
fbshipit-source-id: b2ccd3d3ab9d7e764e41fb54d8a7e60882d1405f
Summary:
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D30015799
Pulled By: sota000
fbshipit-source-id: 9ccfb4b6d477da192a96db4cfa07c31a2d2cefcb
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
Changelog: [Internal]
Previously, the `accessibilityHint` value isn't passed through the underlying component so that the voice over system doesn't announce it. This diff fixes that.
Reviewed By: sammy-SC
Differential Revision: D31017275
fbshipit-source-id: 1bf5a5e36fdfed2a199986b82684a40e18325ba1
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
Modifies `js1 build buckfiles` to also parse files that depend on `ReactSafeMobileConfig` for MobileConfig references.
That module was introduced in {D30470489}.
This fixes a bug where the MobileConfig reference in `ReactNativeInternalFeatureFlags` is not being correctly defined via Metro Buck.
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D30815779
fbshipit-source-id: 156b0838fe47e7ab42c62258a1401875690813a6
Summary:
Removed the deaultProps in the DrawerLayoutAndroid file and replaced it with a default value in case props are undefined.
## Changelog
[General] [Changed] - Remove defaultProps from the DrawerLayoutAndroid Component.�lunaleaps this is the fix for issue https://github.com/facebook/react-native/issues/31606
Pull Request resolved: https://github.com/facebook/react-native/pull/32162
Test Plan: Ran test suite
Reviewed By: lunaleaps
Differential Revision: D30776242
Pulled By: cortinico
fbshipit-source-id: 51408acd92aecb8d725b0bbf39ddb059924481e5
Summary:
the `LogBoxData.addIgnorePatterns` function shows the wrong code to get a item in `Set`. because every item in `set.entries` looks like `[value, value]`, but not `value`.
while the `addIgnorePatterns` function evalutes two itertaions that is not necessary. So I refacted this function.
## 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] - for LogBox checking existingPattern in a wrong way.
[General] [Changed] - addIgnorePatterns runs in one iteration.
[General] [Added] - add a function `getIgnorePatterns` in `LogBoxData.js` for tests or other usecases.
Pull Request resolved: https://github.com/facebook/react-native/pull/31977
Test Plan:
test codes in `LogBoxData-test.js`:
````js
it('adding same pattern multiple times', () => {
expect(LogBoxData.getIgnorePatterns().length).toBe(0);
LogBoxData.addIgnorePatterns(['abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(1);
LogBoxData.addIgnorePatterns([/abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
LogBoxData.addIgnorePatterns(['abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
LogBoxData.addIgnorePatterns([/abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(2);
});
it('adding duplicated patterns', () => {
expect(LogBoxData.getIgnorePatterns().length).toBe(0);
LogBoxData.addIgnorePatterns(['abc', /ab/, /abc/, /abc/, 'abc']);
expect(LogBoxData.getIgnorePatterns().length).toBe(3);
LogBoxData.addIgnorePatterns([/ab/, /abc/]);
expect(LogBoxData.getIgnorePatterns().length).toBe(3);
});
````
and they have passed
Reviewed By: rickhanlonii
Differential Revision: D30675522
Pulled By: yungsters
fbshipit-source-id: 4a05e0f04a41d06cac416219f1e8e540bf0eea02
