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
Summary:
I believe there's a mismatch between the type definitions and the expected prop in Android for `TextInput`'s `autoComplete` prop.
* Android is expecting `autoComplete`.
* JS types are expecting `autoCompleteType`.
* Latest documentation documents `autoCompleteType`.
Prop added here: 179d490607
This change updates the JS types to match what Android is expecting (`autoComplete`). Can update documentation if this is the approach we'd prefer (rather than updating Android to expect `autoCompleteType`).
## Changelog
[Javascript] [Fixed] - Update types for `TextInput`'s `autoComplete` prop.
Pull Request resolved: https://github.com/facebook/react-native/pull/25549
Test Plan:
Before:
* Pass invalid value to `TextInput`'s `autoComplete` prop, see no type errors on JS side, and Android blows up with:
```sh
Invalid autocomplete option: foobar
updateViewProp
ViewManagersPropertyCache.java:95
setProperty
ViewManagerPropertyUpdater.java:132
updateProps
ViewManagerPropertyUpdater.java:51
updateProperties
ViewManager.java:37
```
After:
* Pass invalid value to `TextInput`'s `autoComplete` prop, see PropType warning for `autoComplete` prop.
Differential Revision: D16220809
Pulled By: mdvacca
fbshipit-source-id: e25e198cbcbe721c8d71f069bba293856bf5f36d
Summary:
In order to extend / use `DestructorThread.Destructor` outside of `com.facebook.jni`, we need access modifiers to be less strict:
- `Destructor#Destructor()`: package protected -> public
- `Destructor#destruct()`: package protected -> protected
This will enable Yoga to move from finalizers to `DestructorThread.Destructor` without having to buy into `HybridData` completely.
Reviewed By: cjhopman
Differential Revision: D16182362
fbshipit-source-id: ad616c403df8e7c1e3d751131cfb7a9cfe62cf24
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff fixes a crash caused by an IllegalStateException thrown from the `TextView.onEditorAction()`. This could happen if we don't return false from the `OnEditorActionListener.onEditorAction()` and Android will fallback to the default behaviour, which will try to search and focus the next/previous view in case of `EditorInfo.IME_ACTION_NEXT` or `EditorInfo.IME_ACTION_PREVIOUS` accordingly. Because ReactEditText prevents requesting focus from Android (`ReactEditText.requestFocus()` returns false), the following piece of code from `TextView.onEditorAction()` will crash the app:
```
} else if (actionCode == EditorInfo.IME_ACTION_PREVIOUS) {
View v = focusSearch(FOCUS_BACKWARD);
if (v != null) {
if (!v.requestFocus(FOCUS_BACKWARD)) {
throw new IllegalStateException("focus search returned a view "
+ "that wasn't able to take focus!");
}
}
return;
} else if (actionCode == EditorInfo.IME_ACTION_DONE) {
InputMethodManager imm = InputMethodManager.peekInstance();
if (imm != null && imm.isActive(this)) {
imm.hideSoftInputFromWindow(getWindowToken(), 0);
}
return;
}
```
To prevent this we have to catch `EditorInfo.IME_ACTION_NEXT` and `EditorInfo.IME_ACTION_PREVIOUS` inside `OnEditorActionListener.onEditorAction()` and prevent the default Android behaviour.
Reviewed By: mdvacca
Differential Revision: D16180306
fbshipit-source-id: 6118257c16a7a4a205ae05da671cd76d3a18d565
Summary:
We are deprecating the method UIManagerModule.viewIsDescendantOf as this is not going to be part of Fabric.
For more context: 9ae7f0c7da (commitcomment-34177828)
Reviewed By: fkgozali
Differential Revision: D16186404
fbshipit-source-id: 146600c2da20a7a39c50538741d5822838947f3c
Summary:
Adding viewIsDescendantOf back, more context 9ae7f0c7da
This method might no not be implemented in Fabric
Reviewed By: ejanzer
Differential Revision: D16186407
fbshipit-source-id: bd7a3f46ac8fbe19ba270b2fbf5c324c9400b740
Summary: This diff fixes a potential memory leak which can occur if an exception is thrown inside the try block and `outputStream.close()` is not called. By wrapping `outputStream.write(data)` inside try-with-resource we guarantee that outputStream will be closed regardless of whether the try statement completes normally or abruptly.
Reviewed By: sammy-SC
Differential Revision: D16148850
fbshipit-source-id: c5c0a78b36375857f6e717bb581e8686a4a94bb9
Summary:
[Android] [Added] - Release underlying resources when JS instance is GC'ed on Android
D15826082 was reverted because it introduced a crash in Ads Manager for Android (see P67222724).
This diff fixes the crash and re-applies D15826082. The problem was that `jni::findClassStatic` in the destructor of BlobCollector.cpp couldn't find the Java class `com/facebook/react/modules/blob/BlobModule` and crashed the app.
JNI didn't seem to have access to the Java class loader probably because the destructor was called from a non-Java thread (https://our.intern.facebook.com/intern/wiki/Fbjni/environment-and-thread-management/?vitals_event=wiki_click_navigation_link#threads). The fix is to wrap the code in the destructor inside `ThreadScope::WithClassLoader `, which will allow to run code that has full access to Java as though you were running in a Java thread.
Reviewed By: shergin
Differential Revision: D16122059
fbshipit-source-id: 12f14fa4a58218242a482c2c3e2149bb6770e8ec
Summary:
@public
The `WritableArray` and `WritableMap` interfaces currently require that nested arrays and maps also be writable. Nothing in our code actually relies on this, so we can relax this restriction and get useful properties.
For instance, it is now possible to construct a `JavaOnlyMap` (or array) that reuses `ReadableMap` and `ReadableArray` values by reference ( = structural sharing) instead of forcing a deep copy.
Reviewed By: kathryngray
Differential Revision: D16132580
fbshipit-source-id: 9f41189ebea2a82e775a7a4da8c357a5ce9c5b9d
Summary:
@public
* Removes `JsonWriter`; it's apparently a buggy fork of [`android.util.JsonWriter`](https://developer.android.com/reference/android/util/JsonWriter) which has existed since API level 11. Our version doesn't insert commas before objects or arrays within an array. Instead of fixing it, we can just use the Android one.
* Extends `JsonWriterHelper` to support serialising `ReadableMap`, `ReadableArray` and `Dynamic` values into a `JsonWriter`.
Reviewed By: kathryngray
Differential Revision: D16131713
fbshipit-source-id: d258af42b669f10218cae8b086e7adc3226d16c0
Summary:
All props to Eric Lewis! cc ericlewis
This revert of revert of land of changes originally published in #24873 (with some slight fixes). The change removes usage of LocalData from the `<Text>` component.
After this change we only have ---one (maybe two)--- three components left using LocalData.
Reviewed By: mdvacca
Differential Revision: D15962376
fbshipit-source-id: 19f41109ce9d71ce30d618a45eb2b547a11f29a2
Summary: Now, the signature of `updateState` method practically copies the signature of `updateLocalData`. We need that to support all features that `updateLocalData` does support now (to migrate from it).
Reviewed By: mdvacca
Differential Revision: D15962377
fbshipit-source-id: 61e0af6c191e0c6a358c5859613e9c512f91d29a
Summary: Originally, moving the mount instruction generation under the `if` was a perf optimization but now, since we converge `LocalData` and `State`, this is no longer possible (because we need to treat State as LocalData in some cases).
Reviewed By: mdvacca
Differential Revision: D15962378
fbshipit-source-id: 37f9fadb72ac53450c2d499452610d9835f2964d
Summary: With this, you can load the bundle from another server on the fly. This makes it much easier to hit a named server.
Reviewed By: makovkastar
Differential Revision: D16076020
fbshipit-source-id: 46d78ccd55b9b11481628f4585030494f9282003
Summary:
[Android] [Fixed] - Use HYPHENATION_FREQUENCY_NONE instead of HYPHENATION_FREQUENCY_NORMAL to measure text
The text must be measured with HYPHENATION_FREQUENCY_NONE instead of HYPHENATION_FREQUENCY_NORMAL, since ReactTextView has hyphenation frequency set to HYPHENATION_FREQUENCY_NONE. These two values must match, otherwise the measured height of text we return from the Yoga measure function might be wrong.
Even though the TextView [documentation](https://developer.android.com/reference/android/widget/TextView#setHyphenationFrequency(int)) says that the default hyphenation frequency is HYPHENATION_FREQUENCY_NORMAL before Android Q, it's not true for TextViews instantiated in code (the default value is set from the theme which is missing in case of ReactTextView).
See the screenshots below where the text is measured incorrectly which causes the last line to be cut off.
I extracted the value to a class member variable because I'm planning to expose the hyphenationFrequency prop for the Text component so that it can be configured on Android (as requested by this Github issue: https://github.com/facebook/react-native/issues/17199).
Reviewed By: shergin
Differential Revision: D16109430
fbshipit-source-id: 278c8182c0f819be27bc1d2468559b9e9ae1f807
Summary:
Using Ricky's last changes I managed to subscribe for both new and old event name.
Fixed event to proper one for codegen in native code.
Reviewed By: TheSavior
Differential Revision: D16065660
fbshipit-source-id: b5d3762d673a34bbdf5a8e60ff4d51617c8adb81
Summary: We should annotate `ReactPackageTurboModuleManagerDelegate.getLegacyCxxModule` with `DoNotStrip`, so that ProGuard doesn't strip the method. `ReactPackageTurboModuleManagerDelegate.getModule` doesn't need the annotation because it's used in `TurboModuleManager`.
Reviewed By: fkgozali
Differential Revision: D16097376
fbshipit-source-id: 4b2622e8541fed0ab8fe13b5d0f5d25b58ea39ef
Guilherme Iscaro
Stepan Furdei
Min ho Kim
David Vacca
Oleksandr Melnykov
Joshua Gross
David Aurelio
Eli White
Emily Janzer
Sidharth Guglani
Dan Abramov
Moti Zilberman
Nate
Kevin Gozali
Dan Gilbert
Ram N
Valentin Shergin
Mehdi Mulani
Michał Osadnik
Ramanpreet Nara
