Summary:
The Stale bot closes issues that have been inactive for 97 days (90 days until marked as stale, then 7 days of no activity before it is closed). This helps us focus on issues that affect new releases, and gets rid of drive-by issues where there has been no follow up. This process, however, does not acknowledge there's a type of issue that trascends releases and which the team might want to keep track of in order to fix in a future release.
The "Resolution: Backlog" label can be used to mark these types of issues, and keep the bot from closing them.
[General] [Added] - GitHub: Add Backlog label
Pull Request resolved: https://github.com/facebook/react-native/pull/23789
Differential Revision: D14429112
Pulled By: hramos
fbshipit-source-id: ddec7d994a40e46b43de45b79a812fd4dbd28e6a
Summary:
@public
Removes the configuration field to avoid weak JNI refs. It is no longer used.
Reviewed By: marco-cova
Differential Revision: D14424594
fbshipit-source-id: f0877022615a11ac5079354e0977c6893b7d58d7
Summary:
@public
Completely removes the usage of weak JNI refs.
This is great, because node allocation and deallocation no longer go through a VM-global lock to access the weak reference table.
This is also great, because we can no longer overflow that ref table.
Performance is comparable to weak refs.
Reviewed By: marco-cova
Differential Revision: D14423068
fbshipit-source-id: 62003d2d6fd971e91460a26fb3477046f26e2ba5
Summary:
Fixes#21639 , seems we tried to fix this before, please see related `PR` like [D10392176](36507e4a3c), #18627, but they don't solve it totally.
[iOS] [Fixed] - Fix TextInput maxLength when insert characters at begin
Pull Request resolved: https://github.com/facebook/react-native/pull/23472
Reviewed By: mmmulani
Differential Revision: D14366406
Pulled By: ejanzer
fbshipit-source-id: fc983810703997b48824f84f2f9198984afba9cd
Summary:
Right now we have a raw pointer to the js runtime in Java and we pass that to EventBeatManager's constructor; this diff adds a setter for the runtime ptr and removes it from the member initializer list, so that you can set it later from cpp instead.
Q: Should I just rewrite this to use RuntimeExecutor instead?
Reviewed By: shergin
Differential Revision: D14318893
fbshipit-source-id: 1221dd5959927967bad870f15c901c15e5455874
Summary: Easy cleanup of commented code in TextLayoutManager, I kept the TODOs to complete the code in the future
Reviewed By: shergin
Differential Revision: D14372356
fbshipit-source-id: ff87f9b09e9f40ed021256f463e39299467b3e0e
Summary: This diff is a part of an effort to resolve build errors that appear when compiling with the latest version of clang.
Reviewed By: shergin
Differential Revision: D14369797
fbshipit-source-id: e4c6f53e293f336efad18597f9d2705c025e1051
Summary:
Initially if a `react-native-web` project were to use a library that required internals `expo/webpack-config` would polyfill those internals. This `Platform.web` was used for cases where `react-native` modules needed other internal `react-native` modules, ex: `Animated/src/AnimatedEvent -> Renderer/shims/ReactNative -> Renderer/oss/ReactNativeRenderer-dev -> Core/InitializeCore -> Devtools/setupDevtools -> WebSocket/WebSocket -> Utilities/Platform`
The consensus is that if any `react-native` library references a `react-native` internal (ex: `react-native/*`), it should continue to throw errors. We've removed the use of internals from all of the Unimodules, `react-navigation`, and `react-native-gesture-handler`. This covers a wide enough area for a lot of projects to get web support.
* Add emitters for libs referencing internals necolas/react-native-web#1275
* Remove monkey patch that bundles RN, libs that use internals will crash instead expo/expo-cli#409
* Remove all unsupported internals and polyfills from the Expo suite expo/expo#3676
* Remove internals from react-native-gesture-handler kmagiera/react-native-gesture-handler#406
* Related #23387
[GENERAL] [REMOVED] - Platform.web.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23830
Differential Revision: D14406145
Pulled By: hramos
fbshipit-source-id: bdda99a334d33f5543fdb954eb80e2e7186f985a
Summary:
This change fixes https://github.com/facebook/react-native/issues/23645.
The issue is that the `YGMarker.cpp`, `YGValue.cpp`, `YGConfig.cpp` and `log.cpp` files are already included in the Yoga compilation unit, so including these files in React's compile sources too results in "duplicate symbols" errors when loading React Native with `-force_load` (which behaves slightly differently to `-ObjC` - according to a colleague, "ObjC will scan through each object file in each library and force linking of any object file that contains Objective C code, while force_load will link every object file in a particular staticlib (regardless of whether or not the object file contains Objective C code)").
These changes seemed to be introduced by a few commits:
- D13819111 -> 43601f1a17
- D13439602 -> b5c66a3fbe
- D14123390-> e8f95dc7a1
- D7530369 -> 95f625e151
Perhaps we need to check with the original authors/any C++ experts to confirm if this fix is correct - it compiles for me but I'm not sure what the original intention of these changes was.
[iOS] [Fixed] - Remove duplicated Yoga compile sources to prevent "duplicate symbols" errors when linking using -force_load
Pull Request resolved: https://github.com/facebook/react-native/pull/23823
Reviewed By: davidaurelio
Differential Revision: D14387657
Pulled By: hramos
fbshipit-source-id: d85221b6dc1a0377662624f4201b27222aed8219
Summary: D13103990 updated the flow types for ScrollView. This diff just updates our internal callsites to address the flow errors.
Reviewed By: TheSavior
Differential Revision: D14305453
fbshipit-source-id: 58fe28da06a6c83a81ba29bebe96e74c2f3ed5e5
Summary:
Relates to #22100.
I left 2 `$FlowFixMe`s as I was not sure how to handle generic `React.Element<>` and which native props can I pass to ScrollView (would be cool to document it once we got proper types there).
I also got rid of `InternalScrollViewType` because we have better typings in original `ScrollView` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22301
Reviewed By: TheSavior
Differential Revision: D13103990
Pulled By: RSNara
fbshipit-source-id: 9664ee9d7f570b00992215e10901e5317f24fe5c
Summary:
I measured the performance of UIMananger methods and found that `create` method spends a significant amount of time on preallocating views (around 10 ms on my device). Interestingly, this time was actually spent on dispatching operations on the main thread, not on performing those operations. That makes me think about think about the preallocation problem one more time.
(Here and later I discuss preemptive optimistic preallocation views on iOS, but the issues are more-less applicable for all platforms.)
BTW, what's view preallocation? – In React Native we believe that we can get significant TTI wins instantiating platform views ahead of time while JavaScript thread is busy doing reconciliation and the main one is idle.
So, seems the current approach has those downsides:
* We spend too much time on dispatching only (jumping threads, creation Objective-C blocks, managing them in GCD, incrementing atomic refcountes inside `ShadowView` and so on). That's wasteful.
* We don't have much information during preallocations that can help prepare something to save time in the future. We don't know the future size of the component, so we cannot e.g. pre-draw a border or even allocate memory for a future drawing.
* We pre-allocate to much. At the moment of component creation, we don't know will this component be filtered out by view-flattening infra or not, so we always allocate a view for it. That's ~30% more views that we actually need.
* We don't stop allocating (or dispatching instructions for that) after the recycle pool is already filled in. That's also wasteful.
Why is this so bad and how can we fix it properly?..
I thought about this problem for months. And I think the answer is trivial: We don't know the exact shape of the interface until we finish creating it, and there is no way to overcome this problem on the client side. In the ideal world, the server size (or hardcoded manifest somewhere) tells the renderer (at the moment where we started navigating to it) how many views of which type will some surface use.
And until our world is not so perfect, I think we can get a significant performance improvement doing simple preallocation of 100 regular views, 30 text views, and 30 image views during rendering the first React Native surface. So I hardcoded that.
Reviewed By: JoshuaGross
Differential Revision: D14333606
fbshipit-source-id: 96beeb58b546258de1b8fd58550e0ae412b78aa9
Summary:
This was an idea to check by Joshua Gross
Changelog:
[General][Internal] Codegen: Adding test for negative zero floats
Reviewed By: JoshuaGross
Differential Revision: D14378418
fbshipit-source-id: 4d18eea18143c501d3f2e7ba334f35ec1dd140e6
Summary:
Right now we rely on the Paper UIManager to update animated node graphs - this hooks us into `RCTSurfacePresenter` in the same way so we are no longer reliant on Paper. Should also help with complex ordering corner cases with pre vs. post operations and restoring defaults when nodes are removed. More info:
https://github.com/facebook/react-native/pull/11819/files
Note that we don't have a way to differentiate animation nodes related to fabric views vs. paper views, so if paper and fabric are both rendering updates simultaneously it's possible they could get processed by the wrong callback. That should be very rare, rarely cause problems even if it does happen, and won't be a problem at all in a post-Paper world.
Reviewed By: shergin
Differential Revision: D14336760
fbshipit-source-id: 1c6a72fa67d5fedbaefb21cd4d7e5d75484f4fae
Summary:
We currently rely on the Paper UIManager calling `uiManagerWillPerformMounting` to flush the animated operations queue, which includes starting and stopping animations. This mostly works right now because Fabric always starts after Paper, but sometimes Paper doesn't fire `uiManagerWillPerformMounting` for a while, which can delay an animation starting.
To fix this, I force a flush of the queues on the UIThread whenever start or stop is called. This should be safe because the order of animation operations is still preserved, and start/stop are (almost?) always called in dedicated event handler loops, so any other updates like changing the way nodes are attached should already have been processed from a previous JS execution loop.
Reviewed By: JoshuaGross
Differential Revision: D14313502
fbshipit-source-id: 2a2b0c614fd1a591bd04b6b3fafcc09ff6c9d6e7
Summary: The hope is that it will remove many unnececery allocations improving overal perfromance.
Reviewed By: mdvacca
Differential Revision: D14249198
fbshipit-source-id: f0442b3919ccead0582a3190dea0e33d517d85f6
Summary:
SharedShadowNodeList is one of the core collections in Fabric. Every ShadowNode has one, it's used intensivly during diffing and so on.
Usually, nodes have a very few children, so using `small_vector` instead of regular `vector` should save us a lot of memory allocations.
Reviewed By: JoshuaGross
Differential Revision: D14249201
fbshipit-source-id: 53297caa027a74099d0a1ed4a3cce78f8feb651b
Summary:
Nowadays, every ShadowNode has a reference to a ComponentDescriptor, so now there is no need to do registry lookup for that.
That should save us 0.5-1.0 ms in my non-scientific measurements.
Reviewed By: mdvacca
Differential Revision: D14348369
fbshipit-source-id: 57f6a6f2f8bf0b7e58d89a414fec20b2db8876f7
Summary:
I noticed the links under `## Contents` weren't clickable in the README.md file. This PR makes the links in table of contents clickable again.
[General] [Fixed] - Fix broken links for the table of contents in `README.md`
Pull Request resolved: https://github.com/facebook/react-native/pull/23795
Differential Revision: D14350857
Pulled By: hramos
fbshipit-source-id: ddc02e7905b653cf65ad6ad631bccdbbca936a7f
Summary:
Followup to fe80a0c01d. Use a Markdown extension to let GitHub know this can be rendered as a Preview, otherwise GitHub will display the plaintext version.
[General] [Fixed] - Use Markdown in SUPPORT file
Pull Request resolved: https://github.com/facebook/react-native/pull/23791
Differential Revision: D14349422
Pulled By: hramos
fbshipit-source-id: 836746f35c6e962f3ca64a138bbf764529a6e043
Summary:
I'm changing all callsites to use either global or scoped perf logger explicitly in one diff.
`GlobalPerformanceLogger` is basically a singleton
`scopedPerformanceLogger` is scoped to the React tree by using a React Context
Reviewed By: sahrens
Differential Revision: D14186694
fbshipit-source-id: 062c76eea8fce9d9b531f0eddf153bb79d52f68d
Summary:
See https://help.github.com/en/articles/adding-support-resources-to-your-project. The SUPPORT file is surfaced by GitHub in several useful places. The goal is to increase discoverability of all support resources, giving the reader an opportunity to find the help they need before they open an issue in the repository. A secondary goal is to use a friendlier tone when communicating our processes.
The issue templates have been standardized to follow the format used by GitHub's template tool. A bug in the "Regressions" template, due to its use of multiple labels, is fixed as well.
The bot will explain how a changelog can be fixed when it nags a PR.
[General][Added] - Added SUPPORT resources, friendlier messaging.
Pull Request resolved: https://github.com/facebook/react-native/pull/23778
Differential Revision: D14333911
Pulled By: hramos
fbshipit-source-id: d4b3e75194ea7d5c932dd8df2393d5b189f30f35
Summary:
The `Dockerfile.android` had fallen out of date. We now point to the new community image being used in the Circle CI `test_android` workflow. After spending an hour or two working with these Docker images, I saw some opportunities to clean up the docs as well.
[ANDROID] [Fixed] - Use new React Native Community Android base image for local Docker tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23723
Differential Revision: D14331737
Pulled By: hramos
fbshipit-source-id: cf42820021c997c3c06cc8b3671f67c9d2650ee5
Summary:
androidx files were not being instrumented properly which meant we would have exceptions thrown by powermock
Robolectric Instrumentation config was changed by hand, the remainder is a codemod using abgs + xargs + sed
Differential Revision: D14323745
fbshipit-source-id: 56aa97dad5d7197f4eb0ba1fdd80b1583bcad6ac
Summary:
Clowntown.
This fixes a recent regression happened becasuse wrong order of parameters in ShadowViewMutation constructor.
Reviewed By: JoshuaGross
Differential Revision: D14329164
fbshipit-source-id: 5a0dc04b889fb3357050b951d56c3e436dbeefb1
Summary: Use the codegen for the Slider component with the new `inferfaceOnly` option
Reviewed By: TheSavior
Differential Revision: D14295981
fbshipit-source-id: 0482572892fbcffada43c7c6fbf17e70546300b8
Summary: These were moved to the codgen
Reviewed By: TheSavior
Differential Revision: D14307470
fbshipit-source-id: 49030c245f11bd595bb97e1b2f34a7c454be5c56
Summary: We need this in the Props.h files
Reviewed By: TheSavior
Differential Revision: D14307476
fbshipit-source-id: 34a86ced30e04bfb6d7f85dc292e43d2a1a0ac3e
Summary: In some cases the implementation for native modules are more advanced and we cannot currently generate some of the files. We've decided in these cases to only generate the props + events for now, so this flag `interfaceOnly` will only generate those files 👍
Reviewed By: TheSavior
Differential Revision: D14295980
fbshipit-source-id: 1790825143206a84469015e08958bf6f00ffde52
Summary:
Implement TODO, implement the nativeID functionality in a more efficient way instead of searching the whole view tree.
[iOS] [Fixed] - Implement the nativeID functionality in a more efficient way
Pull Request resolved: https://github.com/facebook/react-native/pull/23662
Differential Revision: D14323747
Pulled By: shergin
fbshipit-source-id: 3d45dbf53ad2b6adb79b4331600d53b51ede76d4
Summary:
This pull request removes the designated initializer in `LayoutMetrics.h`. This will help improve the portability of this file.
[General] [Changed] - Fabric: Remove designated initializer in LayoutMetrics.h
Pull Request resolved: https://github.com/facebook/react-native/pull/23758
Differential Revision: D14320526
Pulled By: shergin
fbshipit-source-id: 076ad389d0985d5213b521a2ffaca4ca7ae31599
Summary:
Keep placeholder paragraph style same with text input.
[iOS] [Fixed] - Keep placeholder paragraph style same with single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23765
Differential Revision: D14321255
Pulled By: cpojer
fbshipit-source-id: 2b8cbb7f2c7ceb40a9a2b142065dd6f5eb3d62eb
Summary:
We always use `NSData` to send, for the `NSString` support, we already transform to `NSData` before call `_sendFrameWithOpcode` method. So we can remove these class check.
Changelog:
----------
[iOS] [Changed] [RCTSRWebSocket] - Remove class check and make data parameter of `_sendFrameWithOpcode` constraint to `NSData`
Pull Request resolved: https://github.com/facebook/react-native/pull/22633
Differential Revision: D14320451
Pulled By: cpojer
fbshipit-source-id: 63ac194d08965d7518a8ac38eea77fd5b43b6147
Summary:
This PR divides the accessibility tests into two activities-- a cross-platform activity for accessibility features which are expected to work on all platforms, and platform specific tests for Android and iOS.
We believe that most, if not all, accessibility features should be cross-platform, with fallback implementations where the underlying concept doesn't exist on a particular platform.
This division of the tests makes it clearer for developers which features are expected to work on all supported platforms, and which are platform-specific.
[CATEGORY] general, Android, iOS
[TYPE] change
Message
Refactor the RNTester accessibility activities to better represent where the features are expected to work. Moves all cross-platform tests to AccessibilityExample.js, Android-specific tests to AccessibilityAndroidExample.android.js, and iOS-specific tests to AccessibilityIOsExample.ios.js.
Pull Request resolved: https://github.com/facebook/react-native/pull/23722
Differential Revision: D14320696
Pulled By: cpojer
fbshipit-source-id: b5ab7a82a90f06d55a24262e86bd69fbdc890427
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed singleline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23745
Differential Revision: D14320630
Pulled By: cpojer
fbshipit-source-id: 2d9e8b59ba70228202add762cfc9c6cbc77e5e95
Summary:
After some refactor of text input attributes, we can now add style attributes the same as text input's attributes, from https://github.com/facebook/react-native/issues/19002#issuecomment-467171589, user wants placeholder to support line-height , I think we can add it now for multiline text input.
[iOS] [Added] - Added lineHeight support of placeholder for multiline text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23760
Differential Revision: D14320600
Pulled By: cpojer
fbshipit-source-id: ededeaa11560af089ca15ffc188e2e70db2ad7d4
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed multiline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23742
Differential Revision: D14320489
Pulled By: cpojer
fbshipit-source-id: 6b0f07fe7406d5c99c7280d584f8b8e51fc84c00
Summary:
when conditional rendering is used then picker breaks when the child is null.
This conditional rendering inside Picker fails when a is 1, because child will be null in PickerAndroid.android.js.
```
{
this.state.a === 2 && <Picker.Item label="value" value="value" />
}
```
[ANDROID] [FIXED] - When child is null it returns.
Pull Request resolved: https://github.com/facebook/react-native/pull/23748
Differential Revision: D14319140
Pulled By: cpojer
fbshipit-source-id: 07d48cd054a131e6984cfe3bdce7538ffbc50622
Summary:
This component is being extracted.
These are flaky and constantly fail on Circle.
[General] [Removed] - Removed Detox e2e Switch tests
Pull Request resolved: https://github.com/facebook/react-native/pull/23753
Differential Revision: D14319130
Pulled By: cpojer
fbshipit-source-id: d0ea276440e034afbb11aa31762922532ad06402
