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:
See the comment in the code.
As part of proper fix of it, we also should remove a line in RCTScrollView that nulls the delegate.
Reviewed By: mdvacca
Differential Revision: D16296050
fbshipit-source-id: 54a4c6c60de4bd97c5cfb44652b5dc26852c540c
Summary:
I finally convinced that we need to add this everywhere.
iOS internals can call those methods at any moment (which is happening in coming diffs), so we cannot predict `_eventEmitter` being not null.
Reviewed By: mdvacca
Differential Revision: D16296052
fbshipit-source-id: 34447c2b5af4117d75930d68593d60bace119bbd
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:
Previously, Fast Refresh socket was initialized lazily. This changes it to be initialized eagerly, even if Fast Refresh is off.
This makes it easier to reason about different states the app can be in. It also lets us later change the code to stash away updates even when Fast Refresh is off — and apply them when you turn it on. (That's out of scope of this diff).
This change should not be user observable. Even if setting up the socket fails, the error is saved, and should only be shown once you turn it on. (AFAIK, D16286232 fixes the last error that was shown unconditionally.)
Reviewed By: rickhanlonii
Differential Revision: D16287232
fbshipit-source-id: a88f9c9f72847074876087da46e19dffa4eb82eb
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:
This fixes a problem that occurs when:
1. You run an Android app with Fast Refresh on
2. Kill the app
3. Start the app again
We used to redbox (on Android only). This is probably because we are missing some check on the native side, and we try to enable the socket anyway.
We could potentially fix this on the native side. But also, there's no good reason why this code needs to ever throw an error if Fast Refresh is disabled.
So I'm unifying it with the existing code path for other Fast Refresh errors. They are ignored when it's off, shown as yellowboxes when it's on, and shown as redboxes if you intentionally try to turn it off and on again.
I'm also adding core to prevent logging more than one Fast Refresh warning. Since they're not super actionable and usually indicate the same problem (e.g. Metro not running). The earliest one wins.
Reviewed By: rickhanlonii
Differential Revision: D16286232
fbshipit-source-id: bf3960f11c767a2352b1282d46950e4ba9e5031d
Summary: These warnings are both noisy and unactionable to product developers when you disconnect a Metro server. You also see them *after* the redbox is closed anyway, so you kind of already know if symbolication didn't work. So I'm downgrading it to a simple log.
Reviewed By: motiz88
Differential Revision: D16285591
fbshipit-source-id: c0e4c9168f66f4573404aa336ab889e4e9da0c22
Summary:
Previously we accepted only very limited set of types for schema parser. However, in many cases we want to provide more specific typings e.g. accept enum or touple.
Currently, we don't take any advantages for codegen from specifying type of elements for object or array. All of them fallback to the same cpp code.
That's why I decided not to throw exception if types of arrays' and objects' elements are different than currently supported. Then I want to fallback to `undefined`.
Reviewed By: rickhanlonii
Differential Revision: D16325028
fbshipit-source-id: 3d7990ca0207c31f0ed522e7316a9cb17b6b1bcb
Summary: We doesn;t support `onError: (string) => void,` is codegen so I change it to `onError: (error: string) => void,`
Reviewed By: TheSavior
Differential Revision: D16284628
fbshipit-source-id: a80a5da54823c827aa0bbe1f1f99613a35605489
Summary: Currently codegen for components supposts stringish. I add it also for components. It fallbacks to StringTypeAnnotation (like in codegen for components).
Reviewed By: rickhanlonii
Differential Revision: D16284381
fbshipit-source-id: 8f03cb79d7e2e1dabbdf4f9353d18dd1daf739fd
Summary: By my mistake previosly it was not poossible to return object defined somewhere in file or return promise containing that object. I changed it to consider value which might be takes from `types` object.
Reviewed By: rickhanlonii
Differential Revision: D16283800
fbshipit-source-id: e9b0ad85b921022732ea0a11db9b58115e87aaa5
Summary: Union type is not supported by codegen and doen not have any impact on generated cpp code so I feel we may get rid of this only one case in favor of any.
Reviewed By: TheSavior
Differential Revision: D16283000
fbshipit-source-id: 210a8fbb7c191031e887d66e28dca048006ce00f
Summary: Currently callback has type `callback: (result: boolean) => mixed` what is pointless (and breaks codegen), because value returning flow callback doesn't have any impact.
Reviewed By: RSNara
Differential Revision: D16282852
fbshipit-source-id: fe1036f17bff307ac91b280727eaa5bf81febd35
Summary: NativeUIManager and NativeAnimatedModule are using nullable args. I believe we may teporarly don't care about that
Reviewed By: RSNara
Differential Revision: D16282683
fbshipit-source-id: 8071a9446c0e1e437391db17c16f82e131094c81
Summary: In this diff I handle the case where the key of an object may be nullable. To do that, I added a nullable param to the schema.
Reviewed By: rickhanlonii
Differential Revision: D16282081
fbshipit-source-id: cb7668d754e2ff30aef22df582351a512c988016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25680
This diff's adding real e2e tests for skeleton added in previous diff.
It verifies many cases for codegen, which should generate cpp code.
Reviewed By: rickhanlonii
Differential Revision: D16279810
fbshipit-source-id: 4441dd0ed4d95476e4071fbd654ebfb8a47ecbfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25673
This diff add e2e code generator validation. I added proper buck rule which compiles cpp code and test if it really compiles.
While testing I faced few minor issues:
- `getBool` and `getNumber` shouldn't have `rt` param.
- Generators now start considering whole module name instead of sliced part of their name.
- Fixed import structure in generated cpp.
- renamed `jsireact` to `ReactCommon` following D16231697
Reviewed By: rickhanlonii
Differential Revision: D16221277
fbshipit-source-id: aff4011ad52dd5e16546ffdb709d6a751ebfaced
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 allows for parsing more flexible AST format.
Reusing logic used for methods, I add similar support for props and commands in components. Now it's possible to define separated type for props and commands in another part of the file.
Also, extracted this method to another file for reusing purposes.
Added tests.
Reviewed By: rickhanlonii
Differential Revision: D16221445
fbshipit-source-id: 21553bf5ade66588dd7dc0320d25333260b0ada9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25671
Moves the RN-specific `ReactFiberErrorDialog` implementation from React to RN for easier iteration. Also adds new unit tests.
This current change is additive, so we're compatible with the current React renderer which still uses `ExceptionsManager` and not the file added here. After the corresponding React update we can remove `ExceptionsManager` from the RN private interface entirely.
Reviewed By: cpojer
Differential Revision: D16278938
fbshipit-source-id: 0c2c0c3e65e524e079730ae3b0cc23e0c0bdc5fd
Summary:
This diff fixes the parsing of the textAlign prop in Fabric. The current parsing does not support 'justify' or 'auto' values.
See https://facebook.github.io/react-native/docs/0.59/text-style-props#textalign for more details about the values of these props in the JS side.
Reviewed By: shergin
Differential Revision: D16269509
fbshipit-source-id: e0d9168d6022245430de644f7c4e45c968b1326b
Summary: It's ok to put VLists in ScrollViews with different scroll directions.
Reviewed By: yungsters
Differential Revision: D16217209
fbshipit-source-id: 7b1c3e93c19867da7414ccda4cda8cc89d25d522
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:
bump gradle-download-task to 4.0.0, works best and tests with Gradle 5.x.
## Changelog
[Android] [Changed] - bump gradle-download-task to 4.0.0
Pull Request resolved: https://github.com/facebook/react-native/pull/25654
Test Plan: RNTester builds and runs as expected
Differential Revision: D16263755
Pulled By: mdvacca
fbshipit-source-id: 39f64d5ff554f99d932e0f3696a1ae5fd4528055
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:
Fixes https://github.com/facebook/react-native/issues/25477
This PR adds a `.prettierrc.js` config file to the HelloWorld template.
`eslint-config-react-native-community` includes custom settings for some rules which conflict with Prettier's default settings.
Consequently, if you run `eslint` immediately after scaffolding a new app you get errors (see linked issue).
This PR configures Prettier to be compatible with both the existing ESLint config and the existing project template (with no code changes to the latter).
## Changelog
[General] [Changed] - Added a default Prettier config for new projects
Pull Request resolved: https://github.com/facebook/react-native/pull/25478
Test Plan:
- The following screenshots show the output of `yarn lint` before and after these changes
- These were run immediate after running `npx react-native-cli init RN060`
### Without these changes
- Linting errors on new projects
- Unfixable automatically due to conflicting rules
<img width="1116" alt="Screenshot 2019-07-03 at 17 44 55" src="https://user-images.githubusercontent.com/2393035/60610078-f6b44d00-9dba-11e9-826f-1524b949e4fd.png">
<img width="1116" alt="Screenshot 2019-07-03 at 17 45 07" src="https://user-images.githubusercontent.com/2393035/60610085-fb790100-9dba-11e9-9a9c-33f4cfefd51e.png">
### With these changes
- Brand new projects will not produce lint errors out of the box
<img width="1116" alt="Screenshot 2019-07-03 at 17 48 25" src="https://user-images.githubusercontent.com/2393035/60610266-57dc2080-9dbb-11e9-8a55-fd09f3549c17.png">
Differential Revision: D16223094
Pulled By: cpojer
fbshipit-source-id: bd2c00b1fcf27b1afcad8c18b357b95a3900bdf7
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
Summary:
Original commit changeset: c45409a8413e
I was unable to find the cause of the problem.
Reviewed By: yungsters
Differential Revision: D16240754
fbshipit-source-id: c1e3f0aa615422f1156706f919e8f851f82c18b0
Summary:
When you call a TurboModule method with JS arguments, we necessarily convert these JS args to Java objects/primitives before passing them to the Java implementation of the method. The problem is that we let the type of the JS arg dictate the type of the Java object/primitive to convert said arg to. This means that if a JS developer passes in an `number` to a function that expects an `Array`, we'll convert the number to a `double` and try to call the Java method with that `double`, when it actually expects a `ReadableArray`. This will trigger a JNI error, and crash the program. Ideally, we should be able to catch these type mismatches early on.
In this diff, on every TurboModule method call, I parse the method signature to determine the Java type of each JS argument. Then, for any argument, if the JS arg and the Java arg types aren't compatible, I raise an exception, which gets displayed as a RedBox in development. This diff also implements support for `?number` and `?boolean` argument and return types in TurboModules.
Reviewed By: mdvacca
Differential Revision: D16214814
fbshipit-source-id: 4399bb88c5344cff50aa8fe8d54eb2000990a852
Chris Blappert
Guilherme Iscaro
Valentin Shergin
Emily Janzer
Sidharth Guglani
David Aurelio
Dan Abramov
Michał Osadnik
Moti Zilberman
David Vacca
Eli White
Spencer Ahrens
Dulmandakh
Nate
JP Driver
Abhishek Ghosh
Samuel Susla
Ramanpreet Nara
Kevin Gozali
