Summary:
Adds a generated view config for iOS Switch
Note: this required some refactoring because the SwitchNativeComponent file included both iOS and android componets, so I broke them out into:
- AndroidSwitchNativeComponent (not generated)
- SwitchNativeComponent (generated)
The schema that we're using is for the iOS version so that's the config that's generated here
Reviewed By: cpojer
Differential Revision: D15495402
fbshipit-source-id: 07b3bc9c780cbf8f6cbf66e976e15981cefcadfa
Summary:
This diff adds the generated view config for UnimplementedNativeView
Note: I believe this component was created in JS just for the codegen because it's unused anywhere
Reviewed By: cpojer
Differential Revision: D15494268
fbshipit-source-id: 8d17465fe59861a299b76565d6edbaf168f45906
Summary: After upgrading `react-native-gesture-handler` in D15701771, we can finally remove this :)
Reviewed By: rubennorte
Differential Revision: D15713072
fbshipit-source-id: 5039478f211a9bdb6ba0d17bed0841e188d00b46
Summary:
This diff updated the codegen flow types syntax replacing:
```
type Options = {
isDeprecatedPaperComponentNameRCT: true,
};
type ActivityIndicatorNativeType = CodegenNativeComponent<
'ActivityIndicatorView',
NativeProps,
Options,
>;
module.exports = ((requireNativeComponent(
'RCTActivityIndicatorView',
): any): ActivityIndicatorNativeType);
```
with:
```
export default codegenNativeComponent<NativeProps>('ActivityIndicatorView', {
isDeprecatedPaperComponentNameRCT: true,
});
```
This is from Tim's comment in the [View Config Codegen Quip](https://fb.quip.com/jR2aASHad4Se):
> What it CodegenNativeComponent were instead `NativeComponent.fromFlow<T>('…')` that returned `'...'`?
>And the Babel plugin swapped it for NativeComponent.fromSchema('...', {…}) which would both register and return '...'?
I went with `codegenNativeComponent` because it has nice parity with `requireNativeComponent`
I also didn't update the babel output here (we can update that whenever) because I think `registerGeneratedViewConfig` is more clear for what it's doing
Reviewed By: cpojer
Differential Revision: D15602077
fbshipit-source-id: 2d24dc32136ba6d31724f8c929b51417ba625a58
Summary:
This diff adds a babel plugin for the generated view configs which will inline them in the file instead of needing to check the view configs in (fb only)
The way it works is:
- babel reads the code
- looks for type alias `CodegenNativeComponent` in `*NativeComponet.js` files
- run the flow parser on the file source to create a schema
- run the schema into codegen to get the view config source code
- inject the generated source code back into the NativeComponent.js file
- remove the original export
- profit
After this diff we will remove the `js1 build viewconfigs` command and the checked-in NativeViewConfig.js files
Note: since this plugin is not published to open source, for now OSS will continue using the `requireNativeComponent` function
Reviewed By: cpojer
Differential Revision: D15516062
fbshipit-source-id: a8efb077773e04fd9753a7036682eeaae9175e09
Summary:
This diff updated the format of generated view configs so that they don't need to spread View props into every config, by adding a new registerGeneratedConfig function which will spread them instead
This is a bit of a cleanup of the generated output but is primarily so that the view config babel plugin will not need to rely on object spreading or object.assigns
Reviewed By: TheSavior, cpojer
Differential Revision: D15517199
fbshipit-source-id: 08e575578177bad12d40ee3dcad9381974b6466d
Summary: This is being removed from RN as part of Lean Core.
Reviewed By: rickhanlonii
Differential Revision: D15666249
fbshipit-source-id: 00612b999184f216cc3deb72c6b24af359060abe
Summary:
This is the same diff as D14786123 but with one of the buck targets fixed that only failed on continuous and didn't run during land time.
This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: rickhanlonii
Differential Revision: D15713305
fbshipit-source-id: caec43c76a6255b2af1693c13d8dea31d7d674f5
Summary:
Hot reloading propagates upwards through the inverse dependency tree — from a file you edited, to the files that import it, and so on. However, we can't always reevaluate everything. Many core infra modules can't run twice, and also the more you run, the more the risk of encountering a module with init side effects. So our practical compromise is to stop the propagation when we reach a module whose exports look like React components. We say that such module "accepts" an update. This means that in practice, changes trigger module reevaluation up to the closest component modules from the edited file. (If you edited a component file, it re-executes alone — unless it exports a non-component.)
However, current implementation has a problem. Sometimes there is an inverse dependency path that has no "accepting" modules whatsoever. For example, maybe you're editing some core module, and its inverse dependency tree reaches goes into React Native itself. Or maybe it reaches the entry point with a bunch of side effects that can't be repeated, like registering the app root component.
In the past, such cases would lead to confusing errors like "Expected `FBPrelude.conclude()` to have been called" after hot reload. This was because we kept re-executing modules all the way upwards, even if there is nothing that can accept the update on the path. Eventually we'd reach top-level modules in the import graph that don't like to run twice.
This diff changes the logic so that we *don't attempt* to re-execute the module factories if we know that some inverse dependency path doesn't terminate in a component. In that case we know we simply *can't apply the hot update* because it doesn't stop at a point we can handle, like a React component.
Since the hot update fails in this case, I'm making it fall back to a regular reload. This is similar to how webpack handles a similar situation on the web. This means that hot updates normally don't refresh, but if we can't apply a hot update to this file, we do refresh automatically.
Reviewed By: cpojer
Differential Revision: D15631864
fbshipit-source-id: 52cd1b03739fd760f1b1b1ab8c7276a150cc3c4c
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
Summary:
`setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`.
This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion.
This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`.
Documentation also updated here: https://github.com/facebook/react-native-website/pull/771
### AppRegistry.js
If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself.
### HeadlessJsTaskSupportModule.java
Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up.
### HeadlessJsTaskContext.java
Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one.
## Changelog
[Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay
Pull Request resolved: https://github.com/facebook/react-native/pull/23231
Differential Revision: D15646870
fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
Summary:
The old whatwg-fetch module doesn't actually export anything, so we would always hit the `else` condition.
The new whatwg-fetch (3.0.0, introduced in #24418) now exports an ES module. As a result, `whatwg` and `whatwg.fetch` are both truthy but the `module.exports` will end up empty. This breaks the RN fetch module.
This will switch the behavior back to the expected polyfill behavior (calling `require('whatwg-fetch')` and allowing it to polyfill fetch in global scope). The RN fetch module will re-export these globals.
Reviewed By: cpojer
Differential Revision: D15639851
fbshipit-source-id: ebd8bce85f7797d8539f53982e515ac47f6425e7
Summary:
Issue reported by Titozzz , `TextInput` would shrink when we have attributes like `lineHeight`.
Demonstration can see GIF like below:
https://giphy.com/gifs/KGNs1qIMHF3DIk1EPK
I think the reason is we apply an empty attributed string to `UITextField`, now if the length is 0, we just nil the `attributedText` instead.
## Changelog
[iOS] [Fixed] - Don't apply empty attributed string for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25143
Differential Revision: D15661751
Pulled By: sammy-SC
fbshipit-source-id: 9770484a1b68a6409e63ea25ac9a6fd0d3589b14
Summary:
Add example showing regression before this fix is applied.
https://github.com/facebook/react-native/pull/18187 Was found to introduce a regression in some internal facebook code-base end to end test which couldn't be shared. I was able to create a reproducible demo of a regression I found, and made a fix for it. Hopefully this will fix the internal test, such that the pr can stay merged.
## Changelog
[GENERAL] [Fixed] - Fix connection of animated nodes and scroll offset with useNativeDriver.
Pull Request resolved: https://github.com/facebook/react-native/pull/24177
Reviewed By: rickhanlonii
Differential Revision: D14845617
Pulled By: cpojer
fbshipit-source-id: 1f121dbe773b0cde2adf1ee5a8c3c0266034e50d
Summary:
Remote debugging stopped working (since 0.58, according to #23254). See https://github.com/facebook/react-native/issues/23254#issuecomment-474692753 for repro steps.
The root cause is incorrect checks for Chrome debugging environment in `UIManager.js`.
- In one place where sync function `lazilyLoadView` should be avoided, we effectively use `if (__DEV__ && !global.nativeCallSyncHook)` to check remote debugging, which misses ship flavor (i.e. `__DEV__` is false).
- In another place where we want to pre-populate view managers' constants to avoid calling sync function `getConstantsForViewManager`, `if (__DEV__)` is used, also missing ship flavor.
This PR fixes both checks, only using the absense of `global.nativeCallSyncHook` to determine remote debugging environments.
## Changelog
[JavaScript] [Fixed] - Correctly bypass sync calls in UIManager during remote debugging
Pull Request resolved: https://github.com/facebook/react-native/pull/25162
Differential Revision: D15692492
Pulled By: cpojer
fbshipit-source-id: 173b688f140916b767fcdbbaaf68a5c303adbcd1
Summary:
There exists race condition in `sendRequest:withDelegate:` method, it can do the session creation multiple times, because we don't lock that, which would leads `EXC_BAD_ACCESS` because use and deallocated session concurrently, we can refer to how to create a singleton safely.
Related https://github.com/facebook/react-native/issues/25152.
## Changelog
[iOS] [Fixed] - Fixes race condition of Network module
Pull Request resolved: https://github.com/facebook/react-native/pull/25156
Differential Revision: D15671734
Pulled By: sammy-SC
fbshipit-source-id: 5021e6cf33c2b55e3f7adf573ab5c8e6a8d82e23
Summary: This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: TheSavior
Differential Revision: D14786123
fbshipit-source-id: 1c49b47d547ad30f2d93c00b44382cf410100b67
Summary: More verbose but descriptive error message when `TurboModule.getEnforcing` fails to find a native module.
Reviewed By: cpojer, gaearon
Differential Revision: D15619293
fbshipit-source-id: 0e8af4986d6ce9002966bb062766218ce9f89a13
Summary:
**This is a manual React sync to replace Haste names with paths so that the removal of Haste is not blocked on a normal React sync. This is a one-time special case; in the future, React will generate renderers that use paths instead of Haste.**
This commit uses the same base commit of React that's currently in RN (React ec6691a68716bc59291746fc62f374a56fb435c9) plus a commit in the React repo that removes Haste-style imports from the renderer (61f62246c8cfb76a4a19d1661eeaa5822ec37b36) and a commit to make the shims import from `implementations` (https://github.com/facebook/react/pull/15786).
I built React in the React repo with `yarn build` and copied over the `oss` directory into one called `implementations` and removed the `*.fb.js` files.
## Changelog
[General] [Changed] - Sync React with Haste-style imports rewritten to use path-based imports instead
Pull Request resolved: https://github.com/facebook/react-native/pull/25100
Reviewed By: yungsters
Differential Revision: D15575646
Pulled By: cpojer
fbshipit-source-id: adf25f9826b71729043b65ba1afd20d14d8c19c4
Summary: Before we flow-typed NativeI18nManager, we defaulted the implementation of I18nManager to something safe when it wasn't available. After the flow-type, it became a requirement that NativeI18nManager be present in the app. This is leading to crashes: T45287329. This diff re-enables the defaults for I18nManager.
Reviewed By: fkgozali
Differential Revision: D15617660
fbshipit-source-id: c3a1c737663a1a4ceae484d0ad6cbf2bd86ffe5f
Summary: This diff adds support for ColorArrayValue in the flow parser
Reviewed By: cpojer
Differential Revision: D15502923
fbshipit-source-id: 6a906b6d609168378fabeb49d0080de011a34d78
Summary: It used a wrong name, so this fixed the module lookup.
Reviewed By: yungsters
Differential Revision: D15595099
fbshipit-source-id: f5a711f595d9630541ae08339aa1532ed1d4d5f2
Summary:
Previously we tried to fix that with RCTUnsafeExecuteOnUIManagerQueueSync but that caused a deadlock (yeah, it's actually unsafe).
Besides that, I tried to solve that with introducing a mutex that covers access to `_operations` and `_preOperations` but failed miserably. It solved threading issue but that didn't fix data-races and inconsistency of the collections.
Reviewed By: sahrens
Differential Revision: D15587564
fbshipit-source-id: d1953036b09354d1663a9b191440f8b4a4e6be9d
Summary: When metro is not running, D15559151 caused infinite exceptions (fetch threw an error if it couldn't connect to localhost:8081) which affected UI. Swallow those errors and everything works well, with or without metro.
Reviewed By: yungsters
Differential Revision: D15588623
fbshipit-source-id: d170ea82478545836a7a22a228196c9778e93ef0
Summary: Some callsites access `UIManager` from `NativeModules.UIManager` instead of importing directly from `UIManager.js`. Post TurboModule spec flow typing, we don't install `getViewManagerConfig()` on the NativeUIManager object anymore, only on the JS wrapper. So callsites not importing from `UIManager.js` will break. Example: https://github.com/react-native-community/react-native-maps/blob/dbf746d66ca1b42f2beb790bfbf4c0e3a74f3279/lib/components/decorateMapComponent.js#L32-L40
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15588353
fbshipit-source-id: 2c2b497dae0660abf15acb2f944546fe03e9bb0a
Summary: This continues the migration off of haste for react-native-github by changing `react-native-implementation` not to use haste.
Reviewed By: JoshuaGross
Differential Revision: D15575896
fbshipit-source-id: 0de7314b7d038a6d603d09ca910f84d580c5cc33
Summary:
This commit more clearly defines the mocks RN sets up and uses paths instead of Haste names to define the mocks. The Jest setup script defined mocks for native modules (Obj-C, Java) and mocks for JS modules in the same data structure. This meant that some non-native modules (that is, JS modules) were in the `mockNativeModules` map -- this commit splits them out and mocks them in typical `jest.mock` fashion.
Additionally, the setup script used to mock the modules using the Haste names. As one of the steps toward migrating to standard path-based imports, the setup script now mocks JS modules using paths (native modules don't need a Haste name nor path since they are just entries in `NativeModules`). This gets us closer to being able to remove `hasteImpl`. (Tracking in https://github.com/facebook/react-native/issues/24772.)
Also, this commit removes mocks that are not referenced anywhere in the RN and React repositories (grepped for the names and found no entries outside of the Jest setup scripts).
## Changelog
[General] [Changed] - Explicitly separate mocked native modules from mocked JS modules
Pull Request resolved: https://github.com/facebook/react-native/pull/24809
Differential Revision: D15316882
Pulled By: cpojer
fbshipit-source-id: 039e4e320121bea9580196fe0a091b8b1e8b41bf
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
The previous comparison does not make sense (accessing props by index) - and always returns true. I'm going to assume there was a reason for implementing `shouldComponentUpdate` - although personally I'd just go for PureComponent (even if it may not be 100% accurate). Let me know if PureComponent sounds better.
## Changelog
not needed
Pull Request resolved: https://github.com/facebook/react-native/pull/25097
Differential Revision: D15575079
Pulled By: cpojer
fbshipit-source-id: 49aeb9d2997d3c613fe7a1af4534dff1607d53b4
Rick Hanlon
Christoph Nakazawa
Chris Blappert
Dan Abramov
Пётр Потапов
Joshua Ong
Arthur Lee
zhongwuzw
Felix Oghina
Mikael Sand
Brian Zhao
Tim Yung
Krzysztof Borowy
James Ide
Sam Goldman
Ramanpreet Nara
Bruno Lemos
Michael Mason
Kevin Gozali
Valentin Shergin
Eric Lewis
mitulsavani
Joshua Gross
Oleg Lokhvitsky
Petr Nikolaev
Rubén Norte
Janic Duplessis
Vojtech Novak