Summary: Changelog: [Internal] - Update XHR upload example to new post test server. Created new toilet here: http://ptsv2.com/t/react-native and configured to return the link to the post data
Reviewed By: kacieb
Differential Revision: D29082824
fbshipit-source-id: 0cb502286addf1de3d5053f73173551ddd180a96
Summary: Changelog: [Internal] - Remove picker from Modal example in RNTester in prep for deprecating Picker from RN
Reviewed By: kacieb
Differential Revision: D29082452
fbshipit-source-id: 01ee5ae2d0978721f7229d824f23cfbccfaf2813
Summary: Changelog: [Internal] - Remove Picker from accessibility example as a first step to deprecate Picker from react-native
Reviewed By: kacieb
Differential Revision: D29082453
fbshipit-source-id: d1d6eb0514453126351b41c2ca5d72d2c81f5dc9
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
Summary:
This PR sets project wide Kotlin version to 1.4.21, supported in Buck https://github.com/facebook/buck/tree/dev/third-party/java/kotlin.
We had to specify version for both kotlin-dsl and kotlin('jvm') plugins to remove version mismatch warnings in **react-native-gradle-plugin**. Also I expect more Kotlin code in RN, so instead of specifying version for each sub-project it's better to have project wide setting.
We don't need to load Kotlin in react-native-gradle-plugin because Kotlin is available RN project wide.
## Changelog
[Internal] [Changed] - Project wide Kotlin version set to 1.4.21
Pull Request resolved: https://github.com/facebook/react-native/pull/31645
Test Plan: Everything works as expected, no visible change for developers.
Reviewed By: yungsters
Differential Revision: D28991440
Pulled By: ShikaSD
fbshipit-source-id: 971fa6f50c12d916a56d0dcde7c65299496fb68a
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## 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] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
This PR aims to enable support for foreground ripple in Pressable. This makes it possible to show ripple on top of custom child components like Image as shown in the below example.
## 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
-->
[Android] [Added] - Support for foreground ripple in Pressable
Pull Request resolved: https://github.com/facebook/react-native/pull/31632
Test Plan:
- Pass property useForeground: true in android_ripple config to verify the changes.
https://user-images.githubusercontent.com/23293248/120111371-4cecbf00-c18f-11eb-8acb-d10718d5483c.mov
Reviewed By: kacieb
Differential Revision: D28926493
Pulled By: yungsters
fbshipit-source-id: 12a6ba71a7dc6ed60fbaeb651f015cace38e03b1
Summary:
Completes example with the swipeable card with swipe-out animation.
The example also tries to reuse the underlying views by ensuring the card reuses the same React node and changes position based on zIndex.
Changelog:
[General][Added] - Added swipeable cards example to RNTester to validate JSResponderHandler
Reviewed By: lunaleaps
Differential Revision: D28492604
fbshipit-source-id: c9fe757100bea9dc787cd754af81e37dc4f084d4
Summary:
allow-large-files
This bumps the flipper dependencies to 0.91.
Fresco deps are not in mavenCentral jet, so picked those from bintray, but pinged the team and they'll follow up on it. See also: https://github.com/facebook/fresco/issues/2603
This primarily bumps to the latest pods we have everywhere, which solves several build issues, like reported in https://github.com/facebook/react-native/issues/31480
After this change it should no longer be needed to pass custom version overrides to `use_flipper`, as the defaults will be up to date.
In the template project, I changed the version rangers to exact numbers, so that results of `react-native init` are more consistent / predictable over time, as suggested in the discord channel by Brent
In the long term we are investigating whether we can remove most of the transitive deps by not using RSocket, which is a bigger project plan that should help reduce build issues and times, especially on iOS.
cc priteshrnandgaonkar passy kelset
## Changelog
[general][changed] - [iOS] Update Flipper to 0.91.1, fixed iOS build support for i386, `use_flipper!()` will no longer need custom overrides to build with XCode 12.5
Pull Request resolved: https://github.com/facebook/react-native/pull/31562
Test Plan:
_N.B. Locally tested in XCode 12.4 only, but bumped versions have been confirmed to work on 12.5 before by others_
* React Native CI
* Flipper CI with same versions of deps: https://github.com/facebook/flipper/actions/runs/863607686
* Was able to connect from both Android and iOS to Flipper. Couldn't really test further due to a bundling error I didn't understand, suggestions welcome
Reviewed By: fkgozali
Differential Revision: D28623601
Pulled By: mweststrate
fbshipit-source-id: 22130d07821569851956453c4ee6a594b6b83928
Summary:
Verifies interaction between PanResponder and ScrollView with JSResponderHandler.
Also showcases how to create a swipeable card with scrollable content.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28093313
fbshipit-source-id: 8ffbe734119912326c471412f4f5e096f64e87cc
Summary:
A few places in RNTester where using hard coded color values, which meant the UI looks broken in dark themes.
The area behind the bookmark button was using a solid color png file, which I've replaced with a color from the theme object.
## Changelog
[Internal] [Fixed] - Fix a couple of places RNTester is using non-theme values
Pull Request resolved: https://github.com/facebook/react-native/pull/31479
Test Plan: Verified in RNTester in react-native-windows in light+dark theme.
Reviewed By: TheSavior
Differential Revision: D28290192
Pulled By: rozele
fbshipit-source-id: 78192200ac2dc8629759c10f8e8b3ec2f6699acd
Summary:
Removes an extra amount of 10dp margin on the top of each example.
Changelog:
[General][Fixed] - Remove excess spacing in RNTester examples.
Reviewed By: kacieb
Differential Revision: D28799736
fbshipit-source-id: 40c8db203f8119359ccc8c40fc0a6424de5afc5e
Summary:
Minor changes to the `Animated` examples index module to make the static typing a bit more intuitive.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799742
fbshipit-source-id: f798631081538e79fc58377105db4e47b9728843
Summary:
Minor reorganization of `AnimatedGratuitousApp` to be a separate top-level directory in `examples/`, like `Animated`.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799737
fbshipit-source-id: b0329e420d6eae912e91d0d74b68ac299c9bd9f3
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
Creates a new RNTester example to verify facebook/react-native#31538 (D28631465).
Changelog:
[Android][Added] - RNTester example for adjusting text with dynamic layout.
Reviewed By: kacieb
Differential Revision: D28779870
fbshipit-source-id: 5297a823645d1e9e35d4c86b491f3c225ecc9543
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Replaces deprecated `translateX` and `translateY` props with `transform` prop in PanResponderExample. This fixes the RNTester example for react-native-windows, which doesn't support the deprecated props.
Changelog:
[General][Fixed] - [RNTester] Use transform prop in PanResponderExample
Reviewed By: kacieb
Differential Revision: D28676164
fbshipit-source-id: 437912b5abf6ca74f0043ded7a902a5938bcf93a
Summary:
Changelog: [internal]
Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes.
Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`.
Reviewed By: JoshuaGross
Differential Revision: D28572283
fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Accessibility service does not announce "selected" on accessibilityState = {selected: true} of the Button Component.
Issue link - https://github.com/facebook/react-native/issues/30956
## 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 accessibilityState prop to Slider component
Pull Request resolved: https://github.com/facebook/react-native/pull/31145
Test Plan:
Verified accessibility states are read by voiceover and talkback. Some state values aren't handled by iOS and have been identified.
Added snapshot tests to test accessibilityState.disabled = disabled values
`js1 test Slider-test`
Reviewed By: yungsters
Differential Revision: D28337723
Pulled By: lunaleaps
fbshipit-source-id: 72a54d8d9dcf1fafb9785c81da99f32a21f3df00
Summary:
While testing 0.65, we noticed issues with hermes on iOS in the template projects
These changes create a subspec to the react-core pod so that it can access hermes header correctly.
## Changelog
Not applicable
Pull Request resolved: https://github.com/facebook/react-native/pull/31559
Test Plan: I've ran e2e manual test. Tested RNTester manually also. Then tested a project inited with hermes and the default template
Reviewed By: mhorowitz
Differential Revision: D28564642
Pulled By: Huxpro
fbshipit-source-id: cfcb3363254f62a0e514ec99159b32f841ee4463
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
Changelog:
[Internal] - In internal e2e testing, json.stringify is unstable and will occasionally re-order keys. Fix so it's consistent across tests
Reviewed By: kacieb
Differential Revision: D28397174
fbshipit-source-id: 0f2db697d245654c88c3dff3d083bc82890d4bc1
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
This is a follow up to my diffs from a couple weeks ago bumping folly version to 2021.04.26. Unfortunately, those diffs did not work when Hermes was enabled, and Flipper was disabled, this fixes that.
I've tested the matrix of Hermes enabled/disabled and Flipper enabled/disabled.
Changelog: [iOS] Fix Hermes + no Flipper build on Xcode 12.5
Reviewed By: yungsters
Differential Revision: D28325790
fbshipit-source-id: e58e1ba4730e7989c48dfd2aae06d91c1d3687db
Summary:
This issue fixes https://github.com/facebook/react-native/issues/30935 screenreader does not announce Image disabled accessibilityState.
As stated in AOSP View.java, the framework will handle routine focus movement, views indicate their willingness to take focus through the `isFocusable` method https://bit.ly/3dCnyHb
```
* <p>The framework will handle routine focus movement in response to user input. This includes
* changing the focus as views are removed or hidden, or as new views become available. Views
* indicate their willingness to take focus through the {link #isFocusable} method. To change
* whether a view can take focus, call {link #setFocusable(boolean)}.
```
The property is updated through its shadow node `ReactImageManager` method `setAccessible` https://bit.ly/3dDuK5L
```java
* <p>Instances of this class receive property updates from JS via @{link UIManagerModule}.
* Subclasses may use {link #updateShadowNode} to persist some of the updated fields in the node
* instance that corresponds to a particular view type.
```
## 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
-->
[Android] [Fixed] - adding setAccessible to ReactImageManager to allow screenreader announce Image accessibilityState of "disabled"
Pull Request resolved: https://github.com/facebook/react-native/pull/31252
Test Plan:
**<details><summary>CLICK TO OPEN TESTS RESULTS</summary>**
<p>
Enable audio to hear the screenreader
TEST SCENARIO
- The user moves the screenreader focus to an image and the screenreader reads the Image accessibilityLabel "plain network image"
RESULT
- The screenreader announces the accessibilityState disabled after reading the Image accessibilityLabel "plain network image"
```javascript
<Image
accessible={true}
accessibilityLabel="plain network image"
accessibilityState={{disabled: true}}
source={fullImage}
style={styles.base}
/>
```
<video src="https://user-images.githubusercontent.com/24992535/112670432-2f366d00-8e61-11eb-843f-4b56f4a06a91.mp4" width="700" />
</p>
</details>
Reviewed By: kacieb
Differential Revision: D28194597
Pulled By: lunaleaps
fbshipit-source-id: 5f89ce5c714405506261885ac6fea2c15c2e1f23
Summary:
Our ESLint configuration currently disallows template literals that can be expressed using plain string syntax (with single quotes). Jest's inline snapshots feature sometimes produces such template literals. This not only adds unnecessary friction from the linter, but can break subsequent snapshot updates in a test file (after accepting the ESLint autofix).
This conflict between Jest and ESLint is a known issue (https://github.com/facebook/jest/issues/10164) with no upstream fix. Here we relax the linter's settings to allow all template literals in test files. Ideally we could allow them *only* in inline snapshots, but this is a reasonable approximation.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D28120785
fbshipit-source-id: c6c6c0ab8a3b8aca14df06f430b777cef42cd554
Summary:
Changelog:
[Internal][Changed] - Fix Picker's item value in the ModalCustomizable example
This surface was removed a few days ago in D27926745 (https://github.com/facebook/react-native/commit/23ae702d97103105a24d85fc7d26f9fb9f15bb3e). Add it back to be able to test Modals manually.
There's no e2e test associated with this surface at the moment.
Reviewed By: nadiia, kacieb
Differential Revision: D28074150
fbshipit-source-id: dbcceed75e982d211b5c74cdf5f80aee59f54678
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 fixes multiple compile errors when building RNTester with Hermes enabled:
- `Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')`
- `'event2/event-config.h' file not found`
- tons of missing files (all added to RCT-Folly/Futures)
Changelog: [iOS] Fix Hermes build on folly version 2021.04.26.00
allow-large-files
Reviewed By: RSNara
Differential Revision: D28128087
fbshipit-source-id: ee7cb6fda72d00d22f6182d958aa8ba55939f158
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
## Context
A React Native application can configure its RCTNetworking by initializing it with id<RCTURLRequestHandler> objects.
Therefore, RCTNetworking supports this initializer:
```
- (instancetype)initWithHandlersProvider:(NSArray<id<RCTURLRequestHandler>> * (^)(void))getHandlers
```
Right now, all id<RCTURLRequestHandler> are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTNetworking](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1471) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the request handlers: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTNetworking gives its _handlersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows the _handlersProvider to load id<RCTURLRequestHandler> from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTNetworking handler provider block RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28013000
fbshipit-source-id: 956d660771ab18f5e7f24fcc28792f9a217146e7
Summary:
## Context
A React Native application can configure its RCTImageLoader by initializing it with two different sets of objects:
- id<RCTImageURLLoader>
- id<RCTImageDataDecoder>
Therefore, RCTImageLoader supports this initializer:
```
- (instancetype)initWithRedirectDelegate:(id<RCTImageRedirectProtocol>)redirectDelegate
loadersProvider:(NSArray<id<RCTImageURLLoader>> * (^)(void))getLoaders
decodersProvider:(NSArray<id<RCTImageDataDecoder>> * (^)(void))getHandlers
```
Right now, both the id<RCTImageURLLoader>s and id<RCTImageDataDecoder>s are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTImageLoader](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1462-1469) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the loaders/decoders: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTImageLoader gives its loadersProvider and decodersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows these two blocks to load the RCTImageURLLoaders and RCTImageDataDecoder from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTImageURLLoader's loader/decoder provider blocks RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28012999
fbshipit-source-id: 09c787923b57bbf72aff95b504f88ee1f2f44283
Luna Wei
Daniel Sainati
Michel Weststrate
Joel Arvidsson
Dulmandakh
Birkir Gudjonsson
Nishan Bende
Andrei Shikov
Michel Weststrate
fabriziobertoglio1987
Andrew
Tim Yung
Dennis Urtubia
Paige Sun
Eric Rozell
Samuel Susla
Ramanpreet Nara
Sladyn Nunes
Thibault Malbranche
Erich Graham
Subramanya Chakravarthy
Micha Reiser
Siddharth Verma
Peter Argany
Moti Zilberman
David Vacca
ananta
Nadiia D
