Summary:
Another trivial sugar/helper to access computed by Yoga layout metrics.
We will use it soon in the new Text render/layout engine.
Reviewed By: mmmulani
Differential Revision: D6671979
fbshipit-source-id: d36933415c2fa50bae5cc171434d8f0b281955b7
Summary: Waiting for layout is now available on main thread.
Reviewed By: mmmulani
Differential Revision: D6719836
fbshipit-source-id: ef655095e999df5f77e69c5931459cce1aaeb1f0
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
Summary: Because setting `intrinsicContentSize` for `RCTSurfaceRootView` doesn't have much sense.
Reviewed By: mmmulani
Differential Revision: D6701107
fbshipit-source-id: 259cdd27339bba3e8c9f98b6ca34affeb87f298c
Summary:
Fix issue #17027 (`RCTModalHostView` has a tvOS dependency that was not wrapped in `TARGET_OS_TV`)
Existing test automation should pass.
[GENERAL] [BUGFIX] [tvOS] Fix cocoapods compile issue in RCTModalHostView
Closes https://github.com/facebook/react-native/pull/17502
Differential Revision: D6688166
Pulled By: hramos
fbshipit-source-id: 38297f439f75a8303f59f83b92e004c6c73d9bf6
Summary:
Essentially, we had `dispatch_async` inside `delloc` method which tried to retain `self`, which is disallowed operation in ObjC runtime.
However, we don't need to notify anything `surface`-related in `_stop` because it always is called from `dealloc`.
Reviewed By: mmmulani
Differential Revision: D6665631
fbshipit-source-id: ed0d192946f3323f4f54ecb99b30e56e0942f174
Summary: Now we do not add newly created view to the registry at the preluminary step.
Reviewed By: mmmulani
Differential Revision: D6641403
fbshipit-source-id: c69077aaba871f3cdb3500c75e1efe07546e1b7f
Summary: Because we already support this for all kinds of shadow views!
Reviewed By: mmmulani
Differential Revision: D6665636
fbshipit-source-id: ceee7e4952ede4bbe54aedde5545587a1d13ea5a
Summary: See `RCTShadowView+Layout.m` for more info about differences between CGFLOAT_MAX and INFINITY in Yoga and UIKit.
Reviewed By: mmmulani
Differential Revision: D6665635
fbshipit-source-id: 270ba5366c3dfe78e38474de5380d7d5d251e628
Summary:
That's now possible thanks to new Yoga's clonning API.
That will speed up RCTSurface measuring (see the next diff in stack) and should illuminate a class of problems in CK interop layer.
We also will use it in the new text layout engine (in React Native).
Reviewed By: gkassabli
Differential Revision: D6665632
fbshipit-source-id: e94909f0af89e9c7fc5e46b95090ecb3c52546a2
Summary:
Yoga and CoreGraphics have different opinions about how "infinity" value
should be represented.
Yoga uses `NAN` which requires additional effort to compare all those values,
whereas GoreGraphics uses `GFLOAT_MAX` which can be easyly compared with
standard `==` operator.
Messing with this can cause super weired bugs like 100% CPU load for couple of seconds somewhere in CoreGraphics.
Reviewed By: mmmulani
Differential Revision: D6665633
fbshipit-source-id: b6236c6fa50d1f8fb0c9576203922f7b24b7301e
Summary:
Those are supposed to replace all `dirtyText`, `dirtyPropagation`, `isPropagationDirty`, `setTextComputed`, `isTextDirty` and so on.
We will use it widely soon (and remove all old ones).
Reviewed By: mmmulani
Differential Revision: D6665634
fbshipit-source-id: 3c1db7154e90b71446756f2495627b163c779996
Summary:
The pull request adds the `--port` option to `run-ios` allowing a developer to build and launch a react-native app using a single command line like this:
```
react-native run-ios --port 8088
```
It defaults to the current port 8081.
This pull request fixes issue #9145 and issue #14113.
This patch also extends `run-android` to properly test and launch the packager with the specified port, extending the work done in PR: ##15316
1. Create a new react-native app, or simply clone this branch and then update your version of react-native using `yarn add file:./path/to/this/fork/of/react-native`
2. run `react-native run-ios --port 8088`
3. watch the packager start on the desired port (8088 in this case) and watch your app in your simulator connect to the packager and launch the app.
Closes https://github.com/facebook/react-native/pull/16172
Differential Revision: D6612534
Pulled By: shergin
fbshipit-source-id: 50af449f5e4c32fb76ba95f4cb7bf179e35526d5
Summary:
Fix calculating layout in `RCTSurfaceRootShadowView` as the `minWidth` is set doubled in `calculateLayoutWithMinimumSize:maximumSize:`.
cc shergin
Closes https://github.com/facebook/react-native/pull/17203
Differential Revision: D6642437
Pulled By: shergin
fbshipit-source-id: 3483c952c9ecf0132182a156b7b916eb1e975424
Summary: This is a leftover from recent changes in D6595780 where a prop application step was moved out to separare mount block.
Differential Revision: D6640736
fbshipit-source-id: 70de0f55f992a7912e222ec4bf9ade1c9bad99f2
Summary:
It's always bothered that we have this protocol and I figured it could just be merged with RCTWrapperViewController.
Closes https://github.com/facebook/react-native/pull/17290
Reviewed By: mmmulani
Differential Revision: D6611544
Pulled By: javache
fbshipit-source-id: a50b9d5adbeb2c48dbadbbfc1c77ccf6d1aae144
Summary:
Nobody uses it.
If the reference to the bridge is available (which is should be case for testing purposes at least), it is easy to get same information.
Reviewed By: mmmulani
Differential Revision: D6596376
fbshipit-source-id: 066eeb1e9465b4e0cc9d9b5b6bf41722450870e4
Summary: The `-[RCTShadowView viewName]` prop must exist, we don't need special handling for this case.
Reviewed By: mmmulani
Differential Revision: D6596375
fbshipit-source-id: 3e99a62bd6296e0285156f03dc2ac93db7f630e5
Summary:
Motivation:
* Current implementation of `didUpdateReactSubviews` relies on `processUpdatedProperties:parentProperties:` method of RCTShadowView, which we plan to remove.
* The existing implementation does not call handlers on unmounted nodes (because they are not part of traversing tree), which is not correct.
* The current implementation is tight with RCTComponentData, which is conceptually wrong, it should be a UIManager thing.
* The new implementation must be much more performant because of simplicity. (We can measure it only after removing `processUpdatedProperties`.)
Reviewed By: mmmulani
Differential Revision: D6595780
fbshipit-source-id: a517207c17b5d5db839c9ce99a37136292acf78c
Summary:
The previous file/class name convention seemed cool... but now it drives me BANANAS! It makes all this code really hard to maintain.
So, evething were renamed following common modern RN convention.
Reviewed By: mmmulani
Differential Revision: D6605090
fbshipit-source-id: 88ca13d793a5d2adaac2b7922ec6bd4654aacec5
Summary: As it was mentioned in previous diffs, we are removing this because it overcomplicates rendering layer and provides (almost) no benefits (and cannot be implemented 100% accurate way).
Reviewed By: mmmulani
Differential Revision: D6582560
fbshipit-source-id: 0778db96a45dd8e2520268d5d00792677cb01a20
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
Reviewed By: mmmulani
Differential Revision: D6549729
fbshipit-source-id: 58094aab982c67cec3d7fa3b616c637cb84d697f
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff replaces usage of `reactBridgeDidFinishTransaction` with `uiManagerDidPerformMounting` which has very similar semantic except that fact that `uiManagerDidPerformMounting` is called asynchronously on the next run loop tick. And this should be okay because new React partial rendering does not guarantee synchronous execution anyways.
Reviewed By: mmmulani
Differential Revision: D6549586
fbshipit-source-id: 589b814f83b91ed8fabf7e638e7554ab3c9d286e
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff replaces usage of `reactBridgeDidFinishTransaction` with `uiManagerDidPerformMounting` which has very similar semantic except that fact that `uiManagerDidPerformMounting` is called asynchronously on the next run loop tick. And this should be okay because new React partial rendering does not guarantee synchronous execution anyways.
Reviewed By: mmmulani
Differential Revision: D6549217
fbshipit-source-id: 2649e943e82e6fbe02c7678583a97db3f5800201
Summary:
Now setting explicit backgroundColor style is required for Views with background shadow,
otherwise the shadow will be generated based on content of the view (which is expected behaviour).
Reviewed By: mmmulani
Differential Revision: D6582587
fbshipit-source-id: 0514cb3c57bad17d2af40810b0e0f7ddc96a2c31
Summary:
This was leftovers from old implementation of zIndex feature.
Janic janicduplessis refactored this and moved all logic to UIView layer, so we don't need this prop anymore in shadow realm.
More info: https://github.com/facebook/react-native/pull/14011
Reviewed By: mmmulani
Differential Revision: D6574414
fbshipit-source-id: 2cae19350765689784d7884ed875878d39b4e3f1
Summary: Following common ObjC pattern, we have to store delegates as weak pointers.
Reviewed By: mmmulani
Differential Revision: D6558886
fbshipit-source-id: 11a710a7e9e17d7c6a78ae46b53b043f44ccf8e5
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff removes `reactBridgeDidFinishTransaction` from RCTScrollView component. As I mentioned, because of the semantic of `reactBridgeDidFinishTransaction` is extremely broad, it's hard to capture what exact case it should handle. Based on comments and existing logic, it seems it tight to `contentSize` property and the size of RCTScrollContentView.
Reviewed By: rsnara
Differential Revision: D6538419
fbshipit-source-id: ccc6f5fea327471f10f1738d3da5214c0d362953
Valentin Shergin
Semen Zhydenko
Spencer Ahrens
Stepan Hruda
Pritesh Nandgaonkar
Douglas
Michael S. Kazmier
Michael Schneider
Alex Dvornikov
Pieter De Baets
Ben Nham
Yujie Liu
Ayush Sood
Alexey Lang
Paco Estevez Garcia
Rahul Ramachandran