Summary:
When code depends on a module from fbjs, its types come from the node_modules
directory. This is problematic when Flow is deployed, since we can't codemod the
parts that come from node_modules.
Reviewed By: dsainati1
Differential Revision: D15547035
fbshipit-source-id: 8794a32e0f5786bcdd80eab98344d4bc623fb674
Summary: Adding flow types for DeviceInfo module and migrating our codebase over to using `DeviceInfo.getConstants()`
Reviewed By: fkgozali
Differential Revision: D14645744
fbshipit-source-id: e30a060c6dc92938cd1420ba11a1d837c79d1e32
Summary: Reverting the generated view configs due to a potential issue
Reviewed By: mdvacca
Differential Revision: D15539319
fbshipit-source-id: bddf923dcfda18bd074196f06610fea8bb4561b4
Summary: This unbreaks an issue at FB.
Reviewed By: rickhanlonii
Differential Revision: D15536623
fbshipit-source-id: 2d59542330d2b951908adf8b6c5c41ca4232bb07
Summary:
We want to phase out usage of config pointers on nodes. Setting configs is no longer needed, as a config is unly used during construction.
Here we deprecate the setter, as it is no longer working as it used to (e.g. changing `useWebDefaults` after a node is constructed).
Reviewed By: SidharthGuglani
Differential Revision: D15416474
fbshipit-source-id: a2cc06cad0c5148cecce056ece5f141b3defe9a9
Summary: Create structure of C++ side of mapbuffer project
Reviewed By: shergin
Differential Revision: D15529650
fbshipit-source-id: b563d3fbcfddcf46802ccb202e372233baad123d
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.
This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)
Reviewed By: mdvacca
Differential Revision: D15501666
fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
Summary:
In Flow v0.99 we are changing function type annotations to be strict about their
static properties. This causes a small issue with the union of a Subcription and
`() => mixed` function type, where the latter is now understood to possibly have
an `unsubscribe` property with a mixed type.
This causes the following refinement check, which appears lower in this file, to
cause an error in the next version of Flow:
```
if (cleanup) {
if (cleanup.unsubscribe) {
cleanup.unsubscribe(); // <-- error here
}
// ...
}
```
In Flow v0.99, because `() => mixed` statics are now checked, Flow sees that
`cleanup.unsubscribe` might be `mixed`, which passes the conditional but could
cause an exception when called.
I also needed to change JestMockFn to have exact statics, because tests
sometimes use a value with that type in place of the cleanup function. That runs
into the `{} <: {+p?: void}` rule, which is an error. `{||} <: {+p?:void}` is
not an error.
Reviewed By: josephsavona
Differential Revision: D15522655
fbshipit-source-id: 2ae3c9016e2b07abaac79827082d2f8743623eb5
Summary: Rick manually created view config in JS for View; adding some missing attributes/events and using this instead of `requireNativeComponent`
Reviewed By: rickhanlonii
Differential Revision: D15488008
fbshipit-source-id: 48e925ec0ca2aeba9e6cc66edef0b70ee1c94d27
Summary:
[Android][Fix] - Fix how we normalize indices
Before, we were incorrectly normalizing indices given pending view deletion in the view hierarchy (namely, using LayoutAnimations)
What we had before (that was wrong):
* Maintained a pendingIndices sparse array for each tag
* For each pendingIndices sparse array we'd keep track of how many views we deleted at each abstract index
* Given an abstract index to delete a view at, we'd consult `pendingIndices` array to sum how many pending deletes we had for indices equal or smaller than and add to abstract index
^ Above algorithm is wrong and you can follow along with the following example to see how.
## The correct approach
Given these operations in this order:
1. {tagsToDelete: [123], indicesToDelete [2]}
2. {tagsToDelete: [124], indicesToDelete [1]}
3. {tagsToDelete: [125], indicesToDelete [2]}
4. {tagsToDelete: [126], indicesToDelete [1]}
The approach we want to be using to calculate normalized indices:
### Step 1: Delete tag 124 at index 2
|Views:|122|123|124|125|126|127|
|Actual Indices:|0|1|2|3|4|5|
|Abstract Indices:|0|1|2|3|4|5|
=> simple, we just mark the view at 2
### Step 2: Delete tag 123 at index 1
View tags and indices:
|Views|122|123|~~124~~|125|126|127|
|Actual indices|0|1|~~2~~|3|4|5|
|Abstract Indices|0|1||2|3|4|
=> again, simple, we can just use the normalized index 1 because no pending deletes affect this operation
### Step 3: Delete tag 126 at index 2
View tags and indices:
|Views|122|~~123~~|~~124~~|125|126|127|
|Actual Indices|0|~~1~~|~~2~~|3|4|5|
|Abstract Indices|0|||1|2|3|
=> Here we want to normalize this index to 4 because we need to account the 2 views that should be skipped
### Step 4: Delete tag 125 at index 1
View tags and indices:
|Views|122|~~123~~|~~124~~|125|~~126~~|127|
|Actual Indices|0|~~1~~|~~2~~|3|~~4~~|5|
|Abstract Indices|0|||1||2|
=> The normalized index should be 3.
This diff updates the function `normalizeIndex` to do the above algorithm by repurposing `pendingIndicesToDelete` to instead be a sparse int array that holds [normalizedIndex]=[tag] pairs
It's required that `pendingIndicesToDelete` is ordered by the normalizedIndex.
Reviewed By: mdvacca
Differential Revision: D15485132
fbshipit-source-id: 43e57dffa807e8ea50fa1650c5dec13a6fded624
Summary:
Changes RNTester, first attempt in the direction of improving the RNTester overall. Related ticket: #24647
Changed the `js` directory of the RNTester to have the following structure:
```
- js
- assets
- components
- examples
- types
- utils
```
* **assets**
_Any images, gifs, and media content_
* **components**
_All shared components_
* **examples**
_Example View/Components to be rendered by the App_
* **types**
_Shared flow types_
* **utils**
_Shared utilities_
## Changelog
[General] [Changed] - Update folder structure of RNTester's JS directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/25013
Differential Revision: D15515773
Pulled By: cpojer
fbshipit-source-id: 0e4b6386127f338dca0ffe8c237073be53a9e221
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/24393 for Android. Allows an app to be opened with an NFC tag and getting the url trough Linking.getInitialURL()
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to set the initialURL
Pull Request resolved: https://github.com/facebook/react-native/pull/25055
Differential Revision: D15516873
Pulled By: cpojer
fbshipit-source-id: e8803738d857a69e1063e926fc3858a416a0b25e
Summary: This removes the JS for ToolbarAndroid from RN and moves it to Ads manager, which has two remaining uses of it. In a follow-up, I will also move the native code.
Reviewed By: rickhanlonii
Differential Revision: D15469117
fbshipit-source-id: 68c3f89b85cc589a48f2dced183267daa791b53b
Summary: Fixes an issue that was including the view config native component verification function even when the native component wasn't included (e.g. on android)
Reviewed By: mdvacca
Differential Revision: D15513535
fbshipit-source-id: 9b615689c0d64757eeb3d66862e5b1902ea79b20
Summary: We need this only until Fabric has own command-execution pipeline.
Reviewed By: mdvacca
Differential Revision: D15501202
fbshipit-source-id: aad77660ada43e429722b13d1da2f998a1726c73
Summary: This is a temporary workaround that we need only temporary and will get rid of soon.
Reviewed By: mdvacca
Differential Revision: D15501203
fbshipit-source-id: cec4891b6a185ea9e39f50bfedf9e1dae8993b66
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
As PR [#24743](https://github.com/facebook/react-native/pull/24743) suggested, accessibility properties are better to set on UIView+React instead of RCTView so they can be used safely on any UIView.
## Changelog
[General] [Fixed] - Move accessibilityActions props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/25015
Differential Revision: D15503131
Pulled By: cpojer
fbshipit-source-id: dedf9afbd0a1d35a5abbd13ace95ee620f718f39
Summary:
Solve #25016
Use `OK` as default text for the affirmative button if no text is specified. When setting an alert on android with button configuration, and no `text` field specified no button is shown on the alert. This makes it impossible to dismiss. An example of how this can happen is creating a simple button where a `onPress` callback is used but no text is specified:
```
Alert.alert(
'title',
'message',
[ { onPress: () => console.log('onPress') } ],
)
```
Does not change the current behavior of no text button configurations on iOS. On iOS at least one button is always shown, and buttons with no text can be displayed.
Behavior on setting multiple buttons is a little wonky, but this PR does not aim to solve it. I did test these cases and included some examples below.
## Changelog
[Android] [Fixed] - Use OK as default text on Android Alert if button configuration specified without text
Pull Request resolved: https://github.com/facebook/react-native/pull/25033
Differential Revision: D15502780
Pulled By: cpojer
fbshipit-source-id: 505a9940f4588f4c10e25b67bfed8b8a1e610c69
Summary:
Okay, I think this is the best I can do David, I don't think there's an obvious/easy way for me to try to get `getIdentifier()` to return a non zero value. Setting it to what Spencer suggested works for my use case.
## Changelog
[Android] [Changed] - Update spinner mode to render spinner instead of calendar
Reviewed By: sahrens
Differential Revision: D15427793
fbshipit-source-id: b04f024a9a1f052f69f3bda47d77821782dc2c0e
Summary:
We are not sure yet how exactly this should work semantically (e.g. should unbatched events flash previously dispatched batched or not).
So, let's disable that until we have all answers.
Reviewed By: mdvacca
Differential Revision: D15498191
fbshipit-source-id: 77f07c5e86bfbfd212505df8cc6530e39531b5ef
Summary:
Same as previous one but for the rest (minority) of methods.
I didn't change `updateLocalData:` because it's going away soon anyway.
Reviewed By: mdvacca
Differential Revision: D15473217
fbshipit-source-id: 6a6bd66c5343211a973fc34ad11e86efe031d07d
Summary:
Passing shared pointers as references can save us a couple of milliseconds at scale.
Originally, I didn't expect that Objective-C supports passing values by references, but apparently it does.
Reviewed By: mdvacca
Differential Revision: D15473218
fbshipit-source-id: 15eb3770cc0889654647a8e91607d8aa78010121
Summary: trivial diff to remove warnings because of the lack of Nullable annotations in MountingManager.ViewState
Reviewed By: shergin
Differential Revision: D15476040
fbshipit-source-id: 2b9a4efa1be1d5aa29d4e32cf32c8ff502f7c60c
Summary: This is an optimization to avoid transfering updateState instructions twice during the frist render of a view (same a props)
Reviewed By: shergin
Differential Revision: D15476041
fbshipit-source-id: 8a62035dbbb63c93f86a2f8d217986a325cb1805
Summary: This diff fixes the rendering of Bottom Sheet in Fabric Android. In D15343702 we added state as part of the "preallocateView" method but we forgot to call viewManager.updateState(), this prevents the state to be updated during the first render.
Reviewed By: shergin
Differential Revision: D15476042
fbshipit-source-id: cd6fc9bdd178589d2e04f85723425b5e5c3e5a04
Summary: This class is not necessary anymore, this diff deletes it from the repo
Reviewed By: JoshuaGross
Differential Revision: D15457346
fbshipit-source-id: c7293d93b50271efe3b3d2121c128ba6e13c7627
Summary:
Adds the generated view config for PullToRefresh
Note: we're not using this view config yet, the component is in the process of being renamed (see TODO)
Reviewed By: rubennorte
Differential Revision: D15485870
fbshipit-source-id: a163ac371181dcc990093e3cd995d7dd9058b26a
Summary:
This diff integrates the new flow parser into `js1 build viewconfig` so that we're generating the view config from actual source
Note: see next diff for usage
Reviewed By: mdvacca
Differential Revision: D15452255
fbshipit-source-id: db04cb1c7adffaf3167a49c2260cae8fd365f50b