Summary: This diff turns on codegen for Slider and Switch
Reviewed By: TheSavior
Differential Revision: D15738544
fbshipit-source-id: a0dfb5b05fd62f28fc3865855986e49598dd5e19
Summary:
This diff adds a testing screen dev route to the facebook app for testing generated view configs
It's not pretty (i have 0 tetra experiance) but it gets the job done
There are three cases handled:
- No generated config �
- Invalid generated config (useful for dev) �
- Valid generated config �
On the description page we:
- Redbox it it's invalid (this could be used to redbox test all host components)
- Show diffs of the view config properties
- List all of the generated config properties
- List all of the native config properties
Using this tool, it's easy to see what the current config on native is, add correct flow types for the generated config, and validate the generated config
Coming later: adding all of the native configs to the list (will probably need filtering)
Reviewed By: cpojer
Differential Revision: D15683033
fbshipit-source-id: 5a566a56bef4f3f0bac3ea581c2e6acb2b9984e3
Summary: D15753278 brokes the build on the armv7 arch. Just backing out this diff and the build works again.
Reviewed By: rzito
Differential Revision: D15758272
fbshipit-source-id: 4e3d3f5322346d31d6160b66b8fef15963baec83
Summary:
This module is being removed from React Native via Lean Core. This diff moves all the related JS files to FB internal.
Note: I removed two references to previously removed modules from some files in this diff. I hope you don't mind.
Reviewed By: TheSavior
Differential Revision: D15714919
fbshipit-source-id: 88ea406396b31f5c255e06d9c92b67127c81db4a
Summary: This module is being removed from RN as part of the Lean Core effort.
Reviewed By: TheSavior
Differential Revision: D15714507
fbshipit-source-id: bb5dc2025a25ad450d6971e5948e7a2e678a9a25
Summary: An attempt to integrate the module flow types with internal codegen infra. Nothing of interest here, other than minor tweak on a spec (we don't support tupples...).
Reviewed By: mdvacca
Differential Revision: D15753278
fbshipit-source-id: b91d564fdbe8f72b90bea725779a9684993472b5
Summary: `verifyComponentAttributeEquivalence` checks the new JS view configs against what we get from native at runtime (in dev only). This breaks in bridgeless mode because there is no paper UIManager to ask for the viewconfigs from; this diff uses the flag from D15721940 to skip this check.
Reviewed By: fkgozali
Differential Revision: D15722127
fbshipit-source-id: d9227107e0ff7814c34beaae6461bb8232699c94
Summary:
In bridgeless mode we don't want to set up the batched bridge, which is set up as part of InitializeCore. Instead of deleting InitializeCore completely, let's just skip this step if we're in bridgeless mode, which we'll detect using a global variable set on the runtime from cpp (`RN$Bridgeless`).
This way you still get an error if the bridge is somehow not set up properly when you're not in bridgeless mode (it won't fail silently).
Reviewed By: fkgozali
Differential Revision: D15721940
fbshipit-source-id: 73896e25874dd000f37d1abc9cf6be549ab3434f
Summary: This diff removes the `React.js` forwarding module from RN open source which was only used for haste requires. I moved this file to FB internal and manually changed requires from `React` to `react`. However, I can't fully remove this forwarding module because we have files shared from www that expect to require React via the capitalized named.
Reviewed By: yungsters
Differential Revision: D15738887
fbshipit-source-id: b5b6c0be258582cfad92c13d174e5490c75152d9
Summary:
Reverse the order in which we look for modules in TurboModuleRegistry to check TurboModules first, and then fall back to legacy native modules. The main motivation for this is Venice, since requiring NativeModules.js fatals because there's no batched bridge. But we'll probably want to do this eventually anyway.
I ran a mobilelab for Marketplace home and am not seeing any significant difference in TTI.
Reviewed By: fkgozali
Differential Revision: D15703655
fbshipit-source-id: d65a4d7e09077474c30fb3938e38aee63bfa4eca
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
Kevin Gozali
Jordan Brown
Rick Hanlon
Yannick Loriot
Christoph Nakazawa
Emily Janzer
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
Valentin Shergin
Eric Lewis
mitulsavani
Joshua Gross
Oleg Lokhvitsky