Summary:
This diff fixes the bug of the switch component on Android being stuck in the middle when a user releases their finger whily dragging the thumb.
When a user releases their finger while dragging the thumb, `setChecked` will be called and if `mAllowChange` is set to false, `super.setChecked` is never called. The supper method will actually make sure the thumb will be animated to the correct edge. Without calling the super method, the thumb might stay in the middle of the switch where a user released their finger.
The fix had to be applied both to ReactSwitch and FbReactSwitchCompat.
One more fix had to be made to FbReactSwitchCompat since D5884661 was applied to ReactSwitch, but not to FbReactSwitchCompat:
if (mAllowChange && **isChecked() != checked**) {
...
}
Reviewed By: mdvacca
Differential Revision: D15535611
fbshipit-source-id: 22ca1fe3fa993ae65cbd677bfae2208a02c368d4
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary: I simply removed them from RN but we should give an actionable error message for people who upgrade from older versions of RN and who may be using these old modules, at least in `__DEV__`.
Reviewed By: rickhanlonii
Differential Revision: D15554863
fbshipit-source-id: 1975d4773581258776d2586ae820677bb14488f6
Summary:
React Native Gesture Handler used to eagerly initialize all of its exports and therefore required a bunch of things from React Native eagerly. When we remove things from RN via the Lean Core project, this leads to failures.
I asked Krzysztof to make a patch release that lazily loads them instead: https://github.com/kmagiera/react-native-gesture-handler/commit/da658c2de2e7135871e27284d9c8c6d323c5d803
Reviewed By: rickhanlonii
Differential Revision: D15554658
fbshipit-source-id: aa4b82e5a3c2c837d160da914f41756d26cd6c07
Summary:
Related #23674, in that PR, we imported background timer support, but it's not sufficient, I think the reason that works is because it enable the `Background Modes` and do some background tasks, for the users who don't enable it, timer would pause immediately before goes into background.
To fix it, we can mark a background task when goes into background, it can keep app active for minutes, try best to support timing when in background.
cc. cpojer .
## Changelog
[iOS] [Fixed] - Timing: Fixes timer when app get into background
Pull Request resolved: https://github.com/facebook/react-native/pull/24649
Differential Revision: D15554451
Pulled By: cpojer
fbshipit-source-id: a33f7afe6b63d1a4fefcb7098459aee0c09145da
Summary:
Part of #24875, adds a spec for Networking. Since `sendRequest` methods are different for both platforms, I had to create 2 spec files as Flow would merge their definitions even when I added `Platform.OS` check
## Changelog
[General] [Added] - TM spec for Networking
Pull Request resolved: https://github.com/facebook/react-native/pull/24892
Reviewed By: RSNara
Differential Revision: D15543067
Pulled By: fkgozali
fbshipit-source-id: 2b91114dfa45e7899bbb139656a30a6fd52e31db
Summary:
part of #24875. I again, am not completely sure how the call site here works- appears settings can be directly accessed?
## Changelog
[General] [Added] - Add TM spec for Settings
Pull Request resolved: https://github.com/facebook/react-native/pull/24879
Reviewed By: RSNara
Differential Revision: D15543012
Pulled By: fkgozali
fbshipit-source-id: a1df3096a2fc5fe8e65d0ed2398912530bd3911a
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
Oleksandr Melnykov
James Ide
Christoph Nakazawa
Johan-dutoit
zhongwuzw
Michał Pierzchała
Wojteg1337
Eric Lewis
Krzysztof Borowy
Sam Goldman
Emily Janzer
Rick Hanlon
michalchudziak
Abhinandan Ramaprasath
David Aurelio
Héctor Ramos
David Vacca
Luna Wei
AndreiCalazans
Andrea Cimitan
Youssouf El Azizi
Daiki Ihara
Michal Sienkiewicz
Valentin Shergin
valerio.ponte
rkang
Sharon Gong
Hermanyo
Malcolm Scruggs
Shen Jin
Dulmandakh
