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
Summary:
On UWP, when the app is executing a Background task, the OS can request it to cancel the task (for various reasons). If the app does not cancel its background task quickly, the OS might terminate the app.
This change adds support to cancel the headless task which can be used by native code to forward the cancellation request from the OS to the JS code.
Pull Request resolved: https://github.com/facebook/react-native/pull/20416
Differential Revision: D10052080
Pulled By: cpojer
fbshipit-source-id: 2c0322ebb45f7835739f68bdf82a7100d968c516
Summary:
Adding some more systrace markers to track load application and the initial bits of MarketplaceHomeApp.
There are a couple big segments worth pointing out with timing from a local `__DEV__: false` run:
* JSBundleRequireTime_end -> BundlePreInitializeCore_start: 360ms
* MobileConfigModuleInit: 210ms
* renderApplication_React_render_start -> MarketplaceHomeAppConstructorSuper_start: 180ms
* MarketplaceHomeAppGetQueryParamsForCachedTopPicks: 100ms
I'm not sure what we can do about any of these except for MarketplaceHomeAppGetQueryParamsForCachedTopPicks where we could break the query params out into a separate file so we don't have to load this 11-thousand-line behemoth just so we can get this snippet:
diffusion/FBS/browse/master/xplat/js/RKJSModules/Apps/Wilde/Marketplace/apps/__generated__/MarketplaceHomeAppQuery.graphql.js$11831-11837
But maybe we have to load it anyway and the query just needs to be optimized (or maybe Relay can optimize the format here).
Reviewed By: yungsters
Differential Revision: D13969695
fbshipit-source-id: 4f39efa6cb591b814687bfe51b02ad92048f1c21
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary:
Fixes two problems I uncovered with React Native:
1. `FBCore/Prelude` points to `React.unstable_AsyncMode` which is not defined. (This type was renamed to `React.unstable_ConcurrentMode` in React v16.6.0. **As a result** people in the "react_native:async_rendering" GK will no longer get runtime errors on app start.
2. Updates `react-devtools` and (more importantly) `react-devtools-core` to 3.4.2 to handle the React-internal tag/type refactoring that happened prior to the release of 16.6.0. **As a result** DevTools will no longer cause a runtime error when connected to React Native.
For the second change, I ran `js1 upgrade react-devtools -v ^3.4.2`
Reviewed By: sebmarkbage
Differential Revision: D13030590
fbshipit-source-id: 603f7f6259f282839039820bcdba4310064a7965
Valentin Shergin
Kevin Gozali
Logan Daniels
Eli White
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
Rick Hanlon
Eric Lewis
Petr Nikolaev
James Ide
Tim Wang
Pieter De Baets
Peter van der Zee
George Zahariev
Alexey Lang
Sivaram Prasad Pulla
Spencer Ahrens
Sam Goldman
Nat Mote
Panagiotis Vekris
Stephy Ma