Summary:
The stack of D17563110 was reverted because it triggered a failing OTA job that wasn't caught at land time.
Fixing the issue by reverting the change to `Route.js` and re-landing the rest of the diff.
Differential Revision: D17564219
fbshipit-source-id: 166b50a163ce8ae226de224882a98c40652e29ac
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary: This indicator is not to be used globally, only to some folks. For now prefix it with (FB-ONLY) since it's only used internally at FB.
Reviewed By: PeteTheHeat
Differential Revision: D17266514
fbshipit-source-id: f22411c26f5f412a1a3da9666f57cffabd2cc017
Summary: This allows to implement `findNodeHandle` in Fabric world (temporary).
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175953
fbshipit-source-id: c88bd1c58608450812799d4ecb4a6bf2c027c5f3
Summary: Instead of showing a thin gray line, don't render anything if no new architecture project is active.
Reviewed By: ejanzer
Differential Revision: D17142557
fbshipit-source-id: 644a8e515c04f84336d80bea00d641c2bfa3be41
Summary: This expands the existing FABRIC overlay to also indicate "TM" if turbomodule is active.
Reviewed By: yungsters
Differential Revision: D16999391
fbshipit-source-id: 42eedb697636c1172e595bc7c1ace2a9367a13b8
Summary: This code was added in D2442406 in Sep 2015. We have other ways to track the calls to these methods these days. I'm not even sure if this works anymore and it isn't called anywhere.
Reviewed By: JoshuaGross
Differential Revision: D16833299
fbshipit-source-id: cad70c06b149ed424122a9a464564835e7a877e5
Summary: While adding support for this to React VR I noticed that `viewConfig.Manager` was `undefined` which meant that the view config never get assigned to the `viewManagerConfigs` object and caused errors later on. This change makes it so that even if `viewConfig.Manager` is not set the viewConfig still gets added to the `viewManagerConfigs` object.
Reviewed By: rickhanlonii
Differential Revision: D16560992
fbshipit-source-id: 626dc133602b142caff60f41d043d02968e6ccfc
Summary: Union type is not supported by codegen and doen not have any impact on generated cpp code so I feel we may get rid of this only one case in favor of any.
Reviewed By: TheSavior
Differential Revision: D16283000
fbshipit-source-id: 210a8fbb7c191031e887d66e28dca048006ce00f
Summary:
This simplifies the first log message for every single reload. Here are the changes:
* I dropped the "application" word because at Facebook we consider these views "surfaces". However, the method is explicitly called "runApplication" because in open source most people will only have a single "application". Removing the word and instead relying on the user specified string avoids the naming problem and doesn't take away from the information.
* I removed the `__DEV__` and performance optimization log. The way RN is set up, developers will always have the correct settings for these in either dev or prod and printing them every time is superfluous. Also, it had a typo. How is it possible nobody ever noticed this?
* I also simplified the invariant below to be half as long. I think it still has the same amount of information with fewer words (this is shown in a RedBox where there isn't that much space)
Reviewed By: rubennorte
Differential Revision: D16108248
fbshipit-source-id: 57351c68fa855c02bfbb1db6416d8db61eab4c19
Summary: The method 'viewIsDescendantOf' is not used in JS, to prevent future usages of this method we just remove it.
Reviewed By: JoshuaGross
Differential Revision: D16014666
fbshipit-source-id: da623a455df04851ce286427fb54849e4e9e720a
Summary:
We should remove all usages of React's legacy context API because it'll be removed from React at some point, it prevents some performance optimizations in updates and can cause conflicts between different context providers (like mixins).
This creates a new Context for `rootTag` (this granularity is intentional) so users that are consuming it via the legacy context API can start migrating away from it.
I didn't create a more generic context (like ReactRootContext, ReactApplicationContext) because having a more granular context makes it easier to track and remove it if we want to, and prevents re-rendering when users only care about certain values.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D14941918
fbshipit-source-id: 7ceea62727d10a591367b7ed7c447309b286758d
Summary:
It turns out that it's expected in certain cases for `UIManager.getViewManagerConfig` to return null: https://fburl.com/4h4pqtd7
Instead of throwing when you try to call that function, let's log something and return null.
Reviewed By: fkgozali
Differential Revision: D15791367
fbshipit-source-id: 71cf14071d877070b4f8b2d72eaa2f10beac38db
Summary:
Replacing UIManager.js with a shim that redirects to either PaperUIManager (containing old impl) or DummyUIManager, if `global.RN$Bridgeless` is set. The UIManager native module doesn't exist in bridgeless mode, which means requiring UIManager.js currently fatals. This is a bit hacky, but it's a lot easier than implementing a dummy native module to make it happy.
I did have to stub out all the properties in UIManagerJSInterface to appease flow, though...
Reviewed By: yungsters
Differential Revision: D15775582
fbshipit-source-id: 8e2628f75b2242971895583696122760acdad7af
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: 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:
`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:
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: 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: 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:
part of #24875. Because some of the methods are rewriteable, I dropped the `+` from the signature, this doesn't feel right to me, but I am not sure if the codegen requires that. If it does, it will probably be better to extend the spec and allow those specific methods to be overriden in a UIManager.js interface. Thoughts on that fkgozali or RSNara?
## Changelog
[General] [Added] - Add TM spec for UIManager
Pull Request resolved: https://github.com/facebook/react-native/pull/24902
Reviewed By: hramos
Differential Revision: D15551356
Pulled By: fkgozali
fbshipit-source-id: 076c4ce635aa7ea41e21cbd67c47ecd562fc320d
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
## Changelog
[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25001
Differential Revision: D15467829
Pulled By: cpojer
fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
Start a `HeadlessJsTaskService` on Android without registered is dangerous on apps because `HeadlessJsTaskService` will acquire a [`PARTIAL_WAKE_LOCK`](https://developer.android.com/topic/performance/vitals/wakelock), without calling `onHeadlessJsTaskFinish` this lock won't release until timeout(if exist). This lock will prevent the android device from sleeping.
Although on JS will throw an error if no headless tasks registered, but it's hard to notice while app in the background. No visual information is displayed.
This PR will log a warning instead of Error, and just mark the task to finished on native if nothing registered in order to release the wake lock.
[Android] [Fixed] - Fix unexpected PARTIAL_WAKE_LOCK when no headless tasks registered.
Pull Request resolved: https://github.com/facebook/react-native/pull/24671
Differential Revision: D15164310
Pulled By: cpojer
fbshipit-source-id: 05b62017ba094d0faabc2848dc8bb6c26101321b
Summary: AppRegistry always hides the small fabric indicator. This allows it to be enabled.
Reviewed By: mdvacca
Differential Revision: D14877831
fbshipit-source-id: 4fe3aac13074641049a9298f5a616aea3138ce93
Summary: These are the same types as the existing measure calls on Paper's UIManager except ReactTag has been replaced with Node
Reviewed By: fkgozali
Differential Revision: D14732142
fbshipit-source-id: b757e0d1f8d168232d8ba58938cdcd3b30e006ff
Summary: We've identified a couple of remaining issues that need to be re-tested before we can ship this more broadly.
Reviewed By: fred2028
Differential Revision: D14775730
fbshipit-source-id: 22402149066c5fbe72c36fcf7f547d63feaf5241
Summary:
Part of: #23313.
This moves the `RCTTest` lib from `Libraries/RCTTest` to `RNTester/RCTTest`. This also removes `takeSnapshot` from React Native, and implements it as a standalone module in RNTester called `ScreenshotManager`.
[General] [Removed] - RCTTest & ReactNative.takeSnapshot
Pull Request resolved: https://github.com/facebook/react-native/pull/23721
Differential Revision: D14434796
Pulled By: PeteTheHeat
fbshipit-source-id: d6e103a0ea0b6702701cdb5ce8449163ca4628ce
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Rick Hanlon
Andres Suarez
Logan Daniels
Eli White
Joshua Gross
Kevin Gozali
Valentin Shergin
Brian Vaughn
Martin Sherburn
Chris Blappert
Michał Osadnik
David Vacca
Christoph Nakazawa
Rubén Norte
Emily Janzer
Yannick Loriot
Joshua Ong
Brian Zhao
Ramanpreet Nara
Eric Lewis
Petr Nikolaev
James Ide
Tim Wang
Pieter De Baets
Peter van der Zee
George Zahariev
Alexey Lang