Summary: This diff registers the new Turbo Module SoundManager in Catalyst, FB4A and Workplace
Reviewed By: JoshuaGross
Differential Revision: D16543432
fbshipit-source-id: de3ab175befd5cc11403159e3aa42e5f17d0a280
Summary: This diff implements the Turbo Module SoundManager, this will be used by following diffs of the stack
Reviewed By: JoshuaGross
Differential Revision: D16543430
fbshipit-source-id: 34ba545f54b759fe4e49d4e3c5f8867205de907c
Summary:
## The Problem
1. `CatalystInstanceImpl` indirectly holds on to the `jsi::Runtime`. When you destroy `CatalystInstanceImpl`, you destroy the `jsi::Runtime`. As a part of reloading React Native, we destroy and re-create `CatalystInstanceImpl`, which destroys and re-creates the `jsi::Runtime`.
2. When JS passes in a callback to a TurboModule method, we take that callback (a `jsi::Function`) and wrap it in a Java `Callback` (implemented by `JCxxCallbackImpl`). This Java `Callback`, when executed, schedules the `jsi::Function` to be invoked on a Java thread at a later point in time. **Note:** The Java NativeModule can hold on to the Java `Callback` (and, by transitivity, the `jsi::Function`) for potentially forever.
3. It is a requirement of `jsi::Runtime` that all objects associated with the Runtime (ex: `jsi::Function`) must be destroyed before the Runtime itself is destroyed. See: https://fburl.com/m3mqk6wt
### jsi.h
```
/// .................................................... In addition, to
/// make shutdown safe, destruction of objects associated with the Runtime
/// must be destroyed before the Runtime is destroyed, or from the
/// destructor of a managed HostObject or HostFunction. Informally, this
/// means that the main source of unsafe behavior is to hold a jsi object
/// in a non-Runtime-managed object, and not clean it up before the Runtime
/// is shut down. If your lifecycle is such that avoiding this is hard,
/// you will probably need to do use your own locks.
class Runtime {
public:
virtual ~Runtime();
```
Therefore, when you delete `CatalystInstanceImpl`, you could end up with a situation where the `jsi::Runtime` is destroyed before all `jsi::Function`s are destroyed. In dev, this leads the program to crash when you reload the app after having used a TurboModule method that uses callbacks.
## The Solution
If the only reference to a `HostObject` or a `HostFunction` is in the JS Heap, then the `HostObject` and `HostFunction` destructors can destroy JSI objects. The TurboModule cache is the only thing, aside from the JS Heap, that holds a reference to all C++ TurboModules. But that cache (and the entire native side of `TurboModuleManager`) is destroyed when we call `mHybridData.resetNative()` in `TurboModuleManager.onCatalystInstanceDestroy()` in D16552730. (I verified this by commenting out `mHybridData.resetNative()` and placing a breakpoint in the destructor of `JavaTurboModule`). So, when we're cleaning up `TurboModuleManager`, the only reference to a Java TurboModule is the JS Heap. Therefore, it's safe and correct for us to destroy all `jsi::Function`s created by the Java TurboModule in `~JavaTurboModule`. So, in this diff, I keep a set of all `CallbackWrappers`, and explicitly call `destroy()` on them in the `JavaTurboModule` destructor. Note that since `~JavaTurboModule` accesses `callbackWrappers_`, it must be executed on the JS Thread, since `createJavaCallbackFromJSIFunction` also accesses `callbackWrappers_` on the JS Thread.
For additional safety, I also eagerly destroyed the `jsi::Function` after it's been invoked once. I'm not yet sure if we only want JS callbacks to only ever be invoked once. So, I've created a Task to document this work: T48128233.
Reviewed By: mhorowitz
Differential Revision: D16589168
fbshipit-source-id: a1c0786999c22bef55d416beb0fc40261447a807
Summary: When you create a TurboModule from the JS side, we instantiate its Java class and simply make this `javaobject` a `jni::global_ref` in C++. But the reason why we need to make this a global ref is because `JavaTurboModule` needs it to be a global reference for method calls. Making this a `jni::global_ref` from the perspective to TurboModuleManager doesn't really make any sense. So, this diff refactors that bit of code.
Reviewed By: mdvacca
Differential Revision: D16555673
fbshipit-source-id: 2778fc5a372c41847e8296c2e22bb9a8826fcc52
Summary:
## Description
When we reload the app, `ReactApplicationContext.destroy()` is called. This method calls `CatalystInstanceImpl.destroy()`, which (on the NativeModules thread) calls `NativeModuleRegistry.notifyJSInstanceDestroy()`, which loops over all its `ModuleHolder`s, and calls `ModuleHolder.destroy()`, each of which call their NativeModule's `onCatalystInstanceDestroy()` method.
TurboModuleManager is a `JSIModule`, so it also has its `onCatalystInstanceDestroy()` method called when the `ReactApplicationContext` is destroyed. But `TurboModuleManager.onCatalystInstanceDestroy()` doesn't do anything. Instead, at the very least, it should call `onCatalystInstanceDestroy()` of all NativeModules.
Reviewed By: mdvacca
Differential Revision: D16552730
fbshipit-source-id: 04459185262e92d69570facb368578a848cc5fdb
Summary: On iOS, calling the `__turboModuleProxy` function with the same name returns the same instance of the TurboModule. Adding this behaviour to Andorid as well.
Reviewed By: mdvacca
Differential Revision: D16553363
fbshipit-source-id: c95e150d6967604a808cfb49877b7a633e33d729
Summary: This fixes the lint that was broken by D16543439
Reviewed By: fkgozali
Differential Revision: D16607092
fbshipit-source-id: 70c3989d25f446ffe0877e58253acef5ada8e010
Summary:
View Pooling is not currently being used in Fabric Android, this diff removes all the extra abstractions that are being used becuase of the unused ViewPooling.
We might add this in the future when we re-implement view correctly.
Reviewed By: JoshuaGross
Differential Revision: D16543439
fbshipit-source-id: f41b6e02fddc36c7ef7a1052399d2e6b2041fcfb
Summary:
We had flex as a reason for both layout and measure. Now creating separating reason flexLayout and flexMeasure in this diff.
Also changed ordering of items in Enum to group layout and measure reasons
Reviewed By: davidaurelio
Differential Revision: D16562350
fbshipit-source-id: 75501f9d4dde0974009193b3991a8acc97b02ad0
Summary: In Dev Settings, we used to have an `Start Sampling Profiler on init` option, which was defunct. This diff re-enables that option. We can now start the Sampling Profiler on app start
Reviewed By: yinghuitan
Differential Revision: D7022382
fbshipit-source-id: 1db85d8a324e401c71187ba5871a91abcc18acf9
Summary:
`createReactContextInBackground` must be run on the UI Thread, so we update the DI annotation from `DefaultIdleExecutor` to `ForUiThread` so that happens.
Unclear why Infer didn't flag this. Asked [here](https://fb.workplace.com/groups/572076376174315/permalink/2661423100572955/).
Also adds an additional thread assert before setting `mHasStartedCreatingInitialContext = true` so that if a similar bug happens in the future, RN won't be completely hosed.
Reviewed By: mdvacca
Differential Revision: D16574901
fbshipit-source-id: 02ba63979904e9df9ef6d782aa7379cb44702508
Summary: For Litho interop and to resolve T47926405, always pass props and state to Create mount item so that any ViewManager can create view instances with knowledge of initial props and state.
Reviewed By: mdvacca
Differential Revision: D16554082
fbshipit-source-id: 3b19a43347b0fa201a054eec60e82fb77cad3625
Summary: I think it's possible that there's a race condition between creating the scheduler and setting the delegate leading to bugs like T47272192.
Reviewed By: mdvacca
Differential Revision: D16537737
fbshipit-source-id: 9c579537658be5a9aeed37c0e4935c997cabb6aa
Summary:
Yesterday we shipped hermesengine.dev as part of the current 0.60 release. This PR brings those changes to master.
## Changelog
[General] [Added] - Added support for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/25613
Test Plan:
* CI is green both on GitHub and at FB
* Creating a new app from source can use Hermes on Android
Reviewed By: cpojer
Differential Revision: D16221777
Pulled By: willholen
fbshipit-source-id: aa6be10537863039cb666292465ba2e1d44b64ef
Summary:
UIManager.measureLayoutRelativeToParent will not be supported as part of fabric.
This diff deprecates this method in the current version or React Native.
Reviewed By: fkgozali
Differential Revision: D16471845
fbshipit-source-id: acfda9bfb2dd8553ff8e359ea2c8d7d88a14c6d2
Summary: I'm only renaming the new `addRootView` that I added (which takes the moduleName, and uses startSurfaceWithConstraints), since the other one implements the UIManager interface method that's shared with paper.
Reviewed By: shergin
Differential Revision: D16432425
fbshipit-source-id: 392af42690052551504676df776bac6d1a968785
Summary: Right now RuntimeExecutor is only used in Fabric. Moving it out of Fabric's uimanager/primitives.h and into react/utils so we can use it more broadly.
Reviewed By: shergin
Differential Revision: D16385366
fbshipit-source-id: 96063e536e1480bac078a9376fe55f7d8750477e
Summary:
This enables Fast Refresh by default.
More concretely:
* For clean installs, it's enabled by default. (You can opt out at any time via the dev menu.)
* For updated DEV apps (on device or simulator), it flips from disabled to enabled **but only if you never touched the setting before**.
* If you previously explicitly enabled and/or later disabled it, we keep your previous setting.
Reviewed By: yungsters
Differential Revision: D16442656
fbshipit-source-id: 1bfe0bf4bcf2830284f9c757fbfacc10db92acb4
Summary:
Since the Android's Picker implementation uses an ArrayAdapter,
it means that the views that were created may be reused for other items
in order to save memory. With this in mind, if one sets the Picker.Item
prop color for only certain items there might be an state that
some items that does not have the color set will end up appearing
with the wrong color. This happens because, this new item is
reusing a view of an item that had the color prop set.
In order to avoid this problem, once a new view is created
the ReactPickerAdapter will save the original color and
re-apply if the item does not have the color prop.
## Changelog
[Android] [Fixed] - Picker.Item displays wrong colors
Pull Request resolved: https://github.com/facebook/react-native/pull/25750
Test Plan:
On android execute the code below. Only the FIRST item should be red.
```javascript
import React from 'react';
import { StyleSheet, View, Picker } from 'react-native';
const values = new Array(100);
for (let i = 0; i < values.length; i += 1) {
values[i] = (i * i).toString();
}
const App = () => {
const [selected, setSelected] = React.useState(0);
const onValueChange = React.useCallback((_, idx) => {
setSelected(idx);
}, []);
return (
<View style={styles.container}>
<Picker onValueChange={onValueChange} selectedValue={values[selected]}>
{values.map((v, i) => (
<Picker.Item
key={v}
value={v}
label={v}
{...(!i ? { color: 'red' } : {})}
/>
))}
</Picker>
</View>
);
};
export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
paddingHorizontal: 20,
},
});
```
### Without the patch
You should see various items with the red color (when only the first one should be red)
### With the patch
Only the first item is red.
Closes https://github.com/facebook/react-native/issues/25456
Differential Revision: D16430961
Pulled By: mdvacca
fbshipit-source-id: 48b41845d465df2e3dd34fc4a76950ddc75a010a
Summary:
The method UIManagerModule.removeSubviewsFromContainerWithID will not be part of fabric. This diff deprecates it to avoid future usage before the migration.
This can not be removed, as it is currently used from React-VR
Reviewed By: shergin
Differential Revision: D16420687
fbshipit-source-id: a06810cabb434e35e5a371444114db2633a35a29
Summary:
The method UIManagerModule.replaceExistingNonRootView will not be part of fabric. This diff deprecates it to avoid future usage before the migration.
This can not be removed, as it is currently used from React-VR
Reviewed By: shergin
Differential Revision: D16420685
fbshipit-source-id: c534e2ee6371698638751f1482bb619db1569733
Summary: Having a cached JS bundle being loaded instead of loading it from Metro can cause recent changes made with Fast Refresh not to be picked up after an app is killed and started again. This diff makes a change so that we always download the bundle from Metro if it's running and only if it's not running we check if there is a cached recent bundle.
Reviewed By: gaearon, davidaurelio
Differential Revision: D16380243
fbshipit-source-id: b2842f718e0c21a3f4ca5ebeb3c2bae1df87a6e1
Summary: Adds a subclass of `YogaNodeJNIBase` that uses `PhantomReference` for deallocating native memory rather than `Object#finalize()`. This should help making garbage collection more efficient.
Reviewed By: amir-shalem
Differential Revision: D16182667
fbshipit-source-id: d310fdb6af184168c43462b24f5e18ab5d0d7ad0
Summary: Easy diff to add extra debug information in the CreateMountItem class. This will be useful to debug bugs in Fabric
Reviewed By: JoshuaGross
Differential Revision: D16381362
fbshipit-source-id: 22073df228908b6c88e6423c4917fc6d64c73f98
Summary: Supporting View Manager Commands on the new UIManager in Fabric. This is needed for things like scrollTo on ScrollView.
Reviewed By: JoshuaGross
Differential Revision: D16175575
fbshipit-source-id: a74effdf7e47b56a150a4e3fb6c4d787659e0250
Summary: Right now we register ReactFabric as a callable module with the bridge so that we can call `ReactFabric.unmountComponentAtNode` in `ReactInstanceManager.detachViewFromInstance`. In bridgeless mode we don't have callable modules, so I'm just setting a global variable that can be called from C++ instead. Using this in a new `unmount` method in FabricUIManager.
Reviewed By: shergin, mdvacca
Differential Revision: D16273720
fbshipit-source-id: 95edb16da6566113a58babda3ebdf0fc4e39f8b0
Summary:
Adds headers in `fb/include/fbjni` to `//ReactAndroid/src/main/jni/first-party/fb:jni`, as these are needed by Yoga now
Fixes compilation of Yoga, after Yoga upgraded its internal copy of *fbjni* and changed header include paths.
## Changelog
[Android] [Fixed] - Fixes compilation of Yoga
Pull Request resolved: https://github.com/facebook/react-native/pull/25711
Test Plan:
```
$ buck build //ReactAndroid/src/main/jni/first-party/yogajni:jni
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 0.5 sec
Building: finished in 2.2 sec (100%) 8/8 jobs, 8 updated
Total time: 2.9 sec
```
Reviewed By: SidharthGuglani
Differential Revision: D16357020
Pulled By: davidaurelio
fbshipit-source-id: 4a97c0d35ebf65412a661ae291b3110bcfba6467
Summary:
The method MountingManager.removeRootView is not used anymore D16275118, I'm deleting from MountingManager
motivation: cleanup as I'm fixing other bugs in Fabric
Reviewed By: ejanzer
Differential Revision: D16350582
fbshipit-source-id: 488cf2aa2feda78e6660a854af5da2718f9905de
Summary:
In order to properly set the view's borderRadius the inner*RadiusX/inner*RadiusY should not
be used, since their values are obtained via the following formula:
int innerTopLeftRadiusX = Math.max(topLeftRadius - borderWidth.left, 0);
If topLeftRadius and borderWidth.left have the same value innerTopLeftRadiusX will
be zero and it will cause the top left radius to never be set since
"(innerTopLeftRadiusX > 0 ? extraRadiusForOutline : 0)" will evaluate to zero.
In order to prevent this issue the condition will only consider topLeftRadius, topRightRadius, and etc.
I took a closer look to see if this fix does not causes a regression in https://github.com/facebook/react-native/issues/22511
## Changelog
[Android] [FIX] - Correctly set the border radius on android
Pull Request resolved: https://github.com/facebook/react-native/pull/25626
Test Plan:
Using the following code and Android certify that the border radius is correctly applied.
```javascript
import React from "react";
import { ScrollView, StyleSheet, Text, View } from "react-native";
export default class App extends React.Component<Props> {
render() {
return (
<ScrollView style={styles.container}>
<View style={styles.box1}>
<Text>borderWidth: 2</Text>
<Text>borderRadius: 2</Text>
</View>
<View style={styles.box2}>
<Text>borderWidth: 2</Text>
<Text>borderRadius: 2.000001</Text>
</View>
<View style={styles.box3}>
<Text>borderWidth: 5</Text>
<Text>borderRadius: 5</Text>
</View>
<View style={styles.box4}>
<Text>borderWidth: 5</Text>
<Text>borderRadius: 5.000001</Text>
</View>
<View style={styles.box5}>
<Text>borderWidth: 10</Text>
<Text>borderRadius: 10</Text>
</View>
<View style={styles.box6}>
<Text>borderWidth: 10</Text>
<Text>borderRadius: 11</Text>
</View>
<View style={styles.box7}>
<Text>borderWidth: 10</Text>
<Text>borderRadius: 5</Text>
</View>
<Text>Testing if this does not cause a regression in https://github.com/facebook/react-native/issues/22511</Text>
<View style={{
margin: 10,
backgroundColor: 'red',
width: 100,
height: 100,
borderWidth: 5,
borderBottomLeftRadius: 15,
}} />
<View style={{
margin: 10,
backgroundColor: 'green',
borderWidth: 5,
width: 100,
height: 100,
}} />
</ScrollView>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1
},
box1: {
margin: 10,
height: 100,
borderRadius: 2,
borderWidth: 2,
borderColor: "#000000"
},
box2: {
margin: 10,
height: 100,
borderRadius: 2.000001,
borderWidth: 2,
borderColor: "#000000"
},
box3: {
margin: 10,
height: 100,
borderRadius: 5,
borderWidth: 5,
borderColor: "#000000"
},
box4: {
margin: 10,
height: 100,
borderRadius: 5.000001,
borderWidth: 5,
borderColor: "#000000"
},
box5: {
margin: 10,
height: 100,
borderRadius: 10,
borderWidth: 10,
borderColor: "#000000"
},
box6: {
margin: 10,
height: 100,
borderRadius: 11,
borderWidth: 10,
borderColor: "#000000"
},
box7: {
margin: 10,
height: 100,
borderRadius: 5,
borderWidth: 10,
borderColor: "#000000"
}
});
```
### Without the fix
### With the fix
Closes https://github.com/facebook/react-native/issues/25591
Reviewed By: osdnk
Differential Revision: D16243602
Pulled By: mdvacca
fbshipit-source-id: 1e16572fdf6936aa19c3d4c01ff6434028652942
Summary:
FabricUIManager.removeRootView() isn't currently used, removing it from the UIManager interface.
It looks like this is called from JS in paper renderers, but not Fabric, so we should be good to delete it.
Reviewed By: shergin, mdvacca
Differential Revision: D16275118
fbshipit-source-id: b8f3ae1dc7574ce17d8cc9e7fee72ef5dcc9b323
Summary:
Upgrades Yoga’s copy of *fbjni* to the latest version.
This will enable us
- to move from `finalize()` to `PhantomReference` to deallocate native memory, with the potential of making GC more efficient.
- to remove the internal dependency to *libfb,* allowing apps without an own dependency to ship less code
Reviewed By: passy
Differential Revision: D16220924
fbshipit-source-id: e8233fe2b5403946ff51f43cb6def558ded52fda
Summary: I originally added `forceFullRefresh` as an escape hatch in case Fast Refresh is too unreliable. In practice we haven't seen any major issues with it. Since this option is already very obscure, I'm just removing it.
Reviewed By: shergin
Differential Revision: D16286632
fbshipit-source-id: c3dc44cffd459912e194e273acf868f3380c64cc
Summary:
Step 1 in removing the dependency on ReactContext from GuardedRunnable and other related classes. These are extensively by native modules and view managers, so in order to remove the bridge dependency from those modules we'll need to first decouple these classes from ReactContext. It turns out they only need ReactContext for its handleException method, which delegates out to product code. For backwards compatibility I'm exposing another NativeModuleExceptionManager in ReactContext that simply wraps its handleException method (since this interface already does everything we need).
I figured I'd keep around an extra constructor that still uses ReactContext for now instead of trying to migrate everything over at once.
Reviewed By: makovkastar
Differential Revision: D16270995
fbshipit-source-id: c9a8714bea7ac2a98e78234a0bae49140c00980d
Summary:
@public
`reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated.
In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`).
This change is backwards compatible in two senses:
1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable.
2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`.
Naturally, both fallbacks mentioned above discard `extraData`.
NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback.
While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes.
Reviewed By: mmmulani
Differential Revision: D16133080
fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
Summary:
@public
Introduces `HasJavascriptExceptionMetadata`, a thin interface to be implemented by all RN (Android) exception classes that represent JavaScript errors (primarily `JavascriptException` and any subclasses).
Also adds a builder-style API for setting the `extraDataAsJson` field on `JavascriptException` instances.
Reviewed By: abhinavbatra
Differential Revision: D16090574
fbshipit-source-id: 427a0d371f1cb4e6fe2e62a91db7857a191fdb8c
Summary: This diff makes the Binding.commitMutex_ recursive, for more context see: D15995971
Reviewed By: shergin
Differential Revision: D16187220
fbshipit-source-id: 559d06e1e4a83d7beee13f41b4549db2b91983e5
Summary:
This diff removes android x dependencies from: react/processing/BUCK
"react/processing" is a java library and it shouldn't have an Android dependency, the purpose of this diff is to fix the CI in RN OSS repository
Reviewed By: makovkastar
Differential Revision: D16247319
fbshipit-source-id: c488ad234c292e85f8fc117634a9f2e51f582e39
Summary: Removed classes YogaNodeJNI and YogaNodeJNIBatching and all the logic have been moved to base class
Reviewed By: davidaurelio
Differential Revision: D16221484
fbshipit-source-id: 830819f5bc6010291b8bc0c6d90897cea991909f
Summary: Removes config param useBatchingForLayoutOutputs and now we are using batching of layout outputs as float array while passing data from c++ to java
Reviewed By: davidaurelio
Differential Revision: D16221483
fbshipit-source-id: 326c668d4dfd13b2cf031f98a84bfa50b1440513
Summary:
This commit fixes an issue where ripple touch feedback extends beyond the border radius of a view.
### Before
<img src="https://user-images.githubusercontent.com/590904/59892832-9cb19180-938f-11e9-8239-b2d5f0e1ce56.png" width="300" />
### After
<img src="https://user-images.githubusercontent.com/590904/59925227-766e0f00-93ec-11e9-9efe-c41e696f8c3c.gif" width="300" />
### The fix
It achieves this by adding a mask to the RippleDrawable background, collecting that information from two new methods on ReactViewGroup:
1. getBorderRadiusMask() returns a drawable rounded rectangle matching the view's border radius properties
2. getBorderRadius() produces a float[] with the border radius information required to build a RoundedRectShape in getBorderRadiusMask()
Additionally, this commit updates setBorderRadius in ReactViewManager to re-apply the background whenever it is set, which is necessary to update the mask on the RippleDrawable background image as the border radius changes.
Related issues:
https://github.com/facebook/react-native/issues/6480
## Changelog
[Android][fixed] - Adding border radius styles to TouchableNative react-native run-android --port <x> correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/25342
Test Plan:
Link this branch to a new React native project with the following App.js class:
```
import React, { Component } from "react";
import { StyleSheet, Text, View, TouchableNativeFeedback } from "react-native";
export default class App extends Component {
render() {
const ripple = TouchableNativeFeedback.Ripple("#ff0000");
return (
<View style={styles.container}>
<TouchableNativeFeedback background={ripple}>
<View
style={{
width: 96,
borderRadius: 12,
borderTopLeftRadius: 10,
borderBottomRightRadius: 37,
height: 96,
alignItems: "center",
justifyContent: "center",
borderColor: "black",
borderWidth: 2
}}
>
<Text>{"CLICK CLICK"}</Text>
</View>
</TouchableNativeFeedback>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: "center",
alignItems: "center",
backgroundColor: "#F5FCFF"
}
});
```
It's important to ensure that updates to border radius are accounted for. I did this by enabling hot module reloading and updating the border radius styles to verify that the ripple remains correct.
Reviewed By: cpojer
Differential Revision: D16221213
Pulled By: makovkastar
fbshipit-source-id: 168379591e79f9eca9d184b1607ebb564c2d83dd
Summary:
Drawing the border in one pass should only be done with the borderWidth and
borderColor are the same for all directions (top, left, bottom and right),
otherwise React may draw wrong colors.
This commit adds a check to verify if all the colors are the same,
otherwise it will draw each quadrilateral independently.
## Changelog
[Android] [Fix] - Properly paint the border colors and there are round borders
Pull Request resolved: https://github.com/facebook/react-native/pull/25649
Test Plan:
Using the code below one must see the correct border colors just like the example below:
### Without the fix
Notice that the first rectangle does not have a transparent top bar and the third rectangle have all borders black
### With the fix
All borders are properly colored.
```javascript
import React from "react";
import { ScrollView, StyleSheet, Text, View } from "react-native";
export default class App extends React.Component<Props> {
render() {
return (
<ScrollView style={styles.container}>
<View style={styles.react1}>
<Text>Top border transparent</Text>
</View>
<View style={styles.react5}>
<Text>Top border transparent - no round corners</Text>
</View>
<View style={styles.react2}>
<Text>all borders green</Text>
</View>
<View style={styles.react3}>
<Text>Green, Red, Blue, Purple colors</Text>
</View>
<View style={styles.react4}>
<Text>Green, Red, Blue, Purple colors - no round corners</Text>
</View>
</ScrollView>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
},
react1: {
alignItems: 'center',
borderWidth: 1,
borderColor: 'red',
borderTopColor: 'transparent',
borderBottomLeftRadius: 15,
borderBottomRightRadius: 15,
paddingVertical: 10,
margin: 10,
marginBottom: 20,
},
react5: {
alignItems: 'center',
borderWidth: 1,
borderColor: 'red',
borderTopColor: 'transparent',
paddingVertical: 10,
margin: 10,
marginBottom: 20,
},
react2: {
alignItems: 'center',
borderWidth: 1,
borderColor: 'green',
borderRadius: 20,
paddingVertical: 10,
margin: 10,
marginBottom: 20,
},
react3: {
alignItems: 'center',
borderWidth: 1,
borderTopColor: 'green',
borderLeftColor: 'red',
borderBottomColor: 'blue',
borderRightColor: 'purple',
borderBottomLeftRadius: 15,
borderBottomRightRadius: 15,
borderTopLeftRadius: 30,
borderTopRightRadius: 30,
paddingVertical: 10,
margin: 10,
marginBottom: 20,
},
react4: {
alignItems: 'center',
borderWidth: 1,
borderTopColor: 'green',
borderLeftColor: 'red',
borderBottomColor: 'blue',
borderRightColor: 'purple',
paddingVertical: 10,
margin: 10,
marginBottom: 20,
},
});
```
Closes https://github.com/facebook/react-native/issues/25643
Differential Revision: D16258526
Pulled By: mdvacca
fbshipit-source-id: 2d43eade23a5a78ccfda8693cc4e2e336ccec156
Summary:
Fix Android CI, this is based on the PR 25632
I changed the original PR to keep buck setting:
```
is_androidx = True,
```
in the file: facebook/react/processing/BUCK as this is required by internal tooling at Facebook.
Differential Revision: D16243600
fbshipit-source-id: 37b59002089b0a321aea71104d35aa210a333b84
David Vacca
Ramanpreet Nara
Sidharth Guglani
Ram N
Spencer Ahrens
Janic Duplessis
Joshua Gross
cpojer
Fred Liu
Emily Janzer
Dan Abramov
Guilherme Iscaro
Stepan Furdei
Min ho Kim
Oleksandr Melnykov
David Aurelio
Eli White
Moti Zilberman
Nate
