Summary:
Android CI was failing due to that it was trying to extract major version from build tools and use it to compile ReactAndroid. Now, it'll extract compileSdkVersion from ReactAndroid/build.gradle and use it.
Issue was that 68c7999c25 dowgraded compileSdk version to 26 while retaining build tools version as 27.0.3, so CI was trying to use SDK 27.
Pull Request resolved: https://github.com/facebook/react-native/pull/21205
Differential Revision: D9943909
Pulled By: hramos
fbshipit-source-id: ec9bc0c40956a16f8088532340722fd43cadde37
Summary:
This PR exposes the `onScrollToTop` event on iOS using the same event-forwarding infrastructure as other ScrollView events. (As such, its `nativeEvent` object reflects the same fields as other ScrollView events.)
Motivation:
----------
If your app is only interested in knowing the position of a ScrollView after a scroll has completed, it can use `onScrollEndDrag` and `onMomentumScrollEnd` to inspect the `contentOffset` after a drag-initiated scroll has finished. (This is much less expensive than observing the `onScroll` event if you only want to know the end position.) However, neither of these `End` events fire if the ScrollView is scrolled to the top by tapping the status bar.
By exposing `onScrollToTop`, it is now possible for an app to cheaply know when such a scroll has completed.
Pull Request resolved: https://github.com/facebook/react-native/pull/21204
Differential Revision: D9943618
Pulled By: hramos
fbshipit-source-id: ac5ee42b7f12d94655ffda617f8f811138da7f6f
Summary:
fix ci path problem on Windows
pass all current ci.
none
[GENERAL] [INTERNAL] [CI] - fix ci path problem on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/21203
Differential Revision: D9943608
Pulled By: hramos
fbshipit-source-id: 66e3e196a6c0015e0472851abeee32de9fef140c
Summary:
This file was created recently but is not used as the WKWebview was integrated directly into the Webview.ios.js
Removing this file to clarify the situation
Pull Request resolved: https://github.com/facebook/react-native/pull/21182
Differential Revision: D9942905
Pulled By: hramos
fbshipit-source-id: 19e9fba94280428edd1deab4a54f8c5dc42a6bfa
Summary:
This diff:
- Disables all tests but one of FabricViewTest
- Disables all tests but one of FabricBenchmarkTest
- Changes ReactAppTestActivity to run with Hermes
The reason there is only one test running in each test class, is because the tear down process of Fabric is still flaky and it produces crashes when restarting RN. We are working on this right now and we will enable the rest of the tests after that's fixed.
Reviewed By: achen1
Differential Revision: D9890700
fbshipit-source-id: a8716481eff15b77bd12b38aaaefd4e282c71f3b
Summary: This diff removes the Fabric Android implementation in favor of Fabric C++, as part of another diff I'm going to move the fabricxx package into fabric package
Reviewed By: shergin
Differential Revision: D9841240
fbshipit-source-id: c7922b7bfb9885f33b1f52237ec7cf00c1df96fb
Summary: This diff adds support for the ActivityIndicator component into the Android Fabric C++ implementation
Reviewed By: shergin
Differential Revision: D9781846
fbshipit-source-id: 952d72556983955875198ac3b7eece6868bc4ae8
Summary:
This PR fixes the formatting of the AppVeyor badge in `README.md` to remove a stray newline that broke formatting.
Pull Request resolved: https://github.com/facebook/react-native/pull/21186
Differential Revision: D9932191
Pulled By: hramos
fbshipit-source-id: f87ad7664d6a0b288615f473ba38b4734b41eb88
Summary:
this is just a suggestion, but as the iPhone 6 is discontinued by Apple
and the new iPhone line will match the X version, it could be good to update the default simulator.
it could also be the iPhone 8, feel free to suggest other changes!
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/21148
Differential Revision: D9928120
Pulled By: hramos
fbshipit-source-id: 005faa3a8e00b67f98a778c92ecc01b064e14199
Summary:
Due to Kureev's cleanup in c4a66a89a2 some arguments are no longer properly passed to metro, but just the default values. This broke the `--projectRoot` and `--watchFolders` arguments used by storybook to change the bundle entrypoint.
This PR simply fixes the regression by assigning these values from argv instead of reading config defaults.
Related: the undocumented `REACT_NATIVE_APP_ROOT` env var is broken, not sure for how long, but I can fix it as a part of this PR or make a new one.
Pull Request resolved: https://github.com/facebook/react-native/pull/21165
Differential Revision: D9929642
Pulled By: hramos
fbshipit-source-id: 00485a0429bd4301de03e5cb455e928878c4ba8f
Summary:
Currently the warning is always triggered, even on iOS. This simply adds a platform check and tweak the message.
Pull Request resolved: https://github.com/facebook/react-native/pull/21174
Differential Revision: D9929679
Pulled By: hramos
fbshipit-source-id: 383f4a820cf5bf261dbfdcff3b950f9812a65e00
Summary:
@public
The React Native CLI is not passing the default `maxWorkers` param to Metro, making it run in a single thread and making the development process really slow.
This fixes https://github.com/facebook/metro/issues/253
Reviewed By: mjesun
Differential Revision: D9915500
fbshipit-source-id: d15030af582e99fe20535c07e751cfe12e444f2f
Summary:
Go back to using compileSdkVersion 26 and targetSdkVersion 26, temporarily. We can re-add this once Android SDK 27 becomes available in Facebook's internal repository.
The Android SDK Build Tools 27.0.3 **are** available, so we can continue using those.
Reviewed By: axe-fb
Differential Revision: D9886607
fbshipit-source-id: 6c1c9c1e1309c3a0483cc4c0bd8dcb4a5f29fc7e
Summary: This diff updates babel-eslint to the stable 9.0.0 version, which uses babel 7.0.0 so we can get rid of babel-7.0.0-beta.52
Reviewed By: rubennorte
Differential Revision: D9894311
fbshipit-source-id: b5276ea7d1b10725fffef13eb1338fe6415dbd36
Summary:
They are bad :D
And they affect us when trying to migrate to the babel runtime helpers
Reviewed By: pvdz
Differential Revision: D9829462
fbshipit-source-id: 15240a56e707e13775d57714646e4960cfe202df
Summary: This diff adds support for image views in Android
Reviewed By: shergin
Differential Revision: D9757712
fbshipit-source-id: 8d33e04c8ac4a670af6ca49bb3b9dccc69d52e40
Summary: This diff fixes the compilation error: "implicit instantiation of undefined template std::hash" when using TextAttributes in Android
Reviewed By: shergin
Differential Revision: D9849407
fbshipit-source-id: 7fcb94b1d4f7715d8037ecbf302d8f345e99e9fd
Summary: This diff introduces the concept of Local Data in Android Fabric C++ and as an example we uses it to implement Text View.
Reviewed By: shergin
Differential Revision: D9583970
fbshipit-source-id: ab7478b16ef4327ff574ca1467870ab9cb684ea0
Summary: In this diff I added support to be able to measure C++ shadowNode in Android. As an example I implemented the measurement of TextViews
Reviewed By: shergin
Differential Revision: D9583972
fbshipit-source-id: 1344782d4c586c94a4576b18a4acfa4775e46952
Summary:
This is an updated (rebased) version of the very old #16579.
I added a [template](https://github.com/facebook/react-native/tree/master/local-cli/templates/HelloNavigation) for react-navigation directly into the React Native repo a long time ago. The feature `react-native init --template foo` supports both:
- Remote templates (`react-native-template-foo` in npm as well as HTTP URLs)
- Local templates that ship with react-native itself
In retrospect, adding the local template wasn't a good idea. Templates should live outside of the React Native repo and be versioned independently. This way templates can be fixed independently of React Native releases, and people can use new templates without having to upgrade React Native.
Pull Request resolved: https://github.com/facebook/react-native/pull/21155
Differential Revision: D9885719
Pulled By: hramos
fbshipit-source-id: d2982f374d3c451c09e348ce5fcdca9d0be5a474
Summary:
Prepack does not understand how to use a random key as an object property. Instead, at build time, it generates a deterministic property name based on a deterministic seed for `Math.random()`.
Prepack would like to move away from this, and keep all the `Math.random()` unevaluated and left in the bundle.
Since this is the only usage of `Math.random()` that can't be handled by the abstract interpreter, it should be changed.
Note that the randomness is not required here at all, it just has to be *some* unique key.
Reviewed By: davidaurelio
Differential Revision: D9882757
fbshipit-source-id: 21c213db9716d2faeb8745d811a620b088a83781
Summary: WKWebViews aren't available on Apple TV. When I landed [the WKWebView stack](https://our.intern.facebook.com/intern/diff/D9362001/), I inadvertently broke the RNTester osTV build. This diff fixes it.
Reviewed By: shergin
Differential Revision: D9844322
fbshipit-source-id: 6de0fbfd13aba38cca7530c9fb486c7cde0afc82
Summary:
@public
These tests are using a mock memory FS to start with, so there is no reason at all they should depend on the host OS or filesystem details. This changeset fixes that so that we fully mock the `fs` and `path` modules dependending on the mock platform (not the host platform). I also added an example of how we can test both platforms (regardless of the host platform) in `findPackageClassName`. Follow up changeset will be to do the same for all the other affected tests.
Related to https://github.com/facebook/react-native/issues/20260.
Reviewed By: mjesun
Differential Revision: D9771024
fbshipit-source-id: b368b43e8e54292d33b6183eec9a9ea69f2e6e76
Summary: This diff introduces a way to convert ParagraphLocalData object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801892
fbshipit-source-id: e50217042a216ea67f28178bb80b136cbb8fb195
Summary: This diff introduces a way to convert AttributedString object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801438
fbshipit-source-id: b762f54917ae90bf53c7f9d07f63b876d1265ece
Summary: This diff introduces a way to convert TextAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9800636
fbshipit-source-id: 592f1cb60a00d3beaecee221259e8914731049d4
Summary: This diff introduces a way to convert ParagrapgAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9798895
fbshipit-source-id: 5b139a079c8681749c3e13938482b47e4153019d
Summary: Actual sizes can be found on the offical website.
Reviewed By: fkgozali
Differential Revision: D9837072
fbshipit-source-id: 38b3f2177629e82740eecc8df4566febbe20815a
Summary:
Use `tools/scm/optimize-gitignore.py` to optimize gitignores in fbcode,
fbandroid, and fbobjc, by moving rules to subdirectories.
Reviewed By: phillco
Differential Revision: D9660076
fbshipit-source-id: 3321ebaafb93e387a11fab000ba9e80afc88b210
Summary:
A bunch of different things was changed, but the most important (and need) change is that `UIManager` is now passed in the function as a regular reference, not as a `shared_ptr`. Besides that fact that passing this as `shared_ptr` is simply incorrect (because there is no ownership sharing/transferring here), we need this change because we cannot construct `shared_ptr` from `this` inside `UIManager` class (especially in the constructor).
Besides that:
* `const &` everything (correctness, explicit intention, performance);
* Names were unified with the rest of the code;
* `auto` everything;
* All JSI stuff is now explicitly prefixed with `jsi::`;
* `using` instead of `typedef` (modern C++ syntax);
* Lamdas instead of std::bind (same perfromance, much more clear and flexible);
Reviewed By: mdvacca
Differential Revision: D9835901
fbshipit-source-id: 935be0ae889fe5508ffa9498282c939c816587e1
Summary: In modern C++ `const` basically means `thread-safe` and we commit that all that methods are thread-safe.
Reviewed By: mdvacca
Differential Revision: D9836100
fbshipit-source-id: 4241ca80da77338b25246e622cf8d7e8c360eff7
Summary:
The spec says that `bridge_transfer` indicates that we "transfer ownership of the pointer" to ARC which implies that as soon this part of the code does not need the object, it will be deallocated. However, that's not what we want here. This object is actually already owned by another ARC-powered code somewhere else and the pointer to it was transferred as a raw pointer through the C++ world.
So, we want to keep the ownership of the object on the other side but still imply the lifetime of the object. So how can we do that? Simple, we have to use `bridge`.
Why? ARC is not magical, it's just automatic ref counting. And I think the only difference between `bridge` and `bridge_transfer` is how many refcounter's bumps will be added to the generated code. In the case of `bridge_transfer` it is zero, in the case of `bridge` it is one. So, initializing a new Objective-C variable that points to the shared resource we have to bump the counter once, so we have to use `bridge`.
Reviewed By: mdvacca
Differential Revision: D9819405
fbshipit-source-id: 9e7af343917ec4407a64d884402b10ee2a8097f9
Summary: We will need that to manage collections of attributed strings.
Reviewed By: mdvacca
Differential Revision: D9803351
fbshipit-source-id: 0ea9719f97ed30ff6dfe17b6dbebf448afe228b3
Summary: We will need this eventually.
Reviewed By: mdvacca
Differential Revision: D9799852
fbshipit-source-id: 0411e2f41540273c80f425e04c877fe51b9b2374
Summary:
To dispatch events synchonously on the main thread we still have to block the Message Queue.
We actually dispatch events on the Message Queue while the main thread is waiting.
Reviewed By: mdvacca
Differential Revision: D9799853
fbshipit-source-id: 8033be36f27371ad2f1dc7210d564fbca1174910
Summary: This one gets rid of the dependency on `metro-visualizer`
Reviewed By: mjesun
Differential Revision: D9829876
fbshipit-source-id: e3a52a2771bee386f8c1276004065fe480b3fc52
Summary:
I realized that instead of using shared_ptr's type-erasure feature, we can make the EventHandler's destructor virtual and this itself will allow safe deallocation by a pointer to a base class.
We cannot use the same technic for EventTarget thought because having a weak_ptr to this is another feature of shared_ptr that we need.
Reviewed By: mdvacca
Differential Revision: D9775742
fbshipit-source-id: 3c23a163827e8aa9ec731c89ce87051a93afe4ca
Summary: Instead of relying on explicit `RawEventDispatchable` function, we simply check the existence of the `weak_ptr` to `EventTarget`. This is efficient and sufficient because only an EventEmitter retains an associated EventTarget.
Reviewed By: mdvacca
Differential Revision: D9764858
fbshipit-source-id: 4ac25d925f189d0f8b9002e52388fd51629934a8
Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
Summary:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
This PR tries to consolidate Android native dependencies versions to make it less error prone to version bumps.
Pull Request resolved: https://github.com/facebook/react-native/pull/20742
Differential Revision: D9818155
Pulled By: hramos
fbshipit-source-id: 9bf631640910edad5731014f4e23dbca45af2b59
David Aurelio
Tim Yung
Miguel Jimenez Esun
Dulmandakh
James Reggio
gengjiawen
Thibault Malbranche
David Vacca
empyrical
Vitor Capretz
Joel Arvidsson
Janic Duplessis
Héctor Ramos
Nat Mote
Rafael Oleza
Martin Konicek
Riley Dulin
Ramanpreet Nara
Jean Lauliac
Valentin Shergin
Jun Wu