Summary:
Trivial.
Special thanks to janicduplessis
Created from Diffusion's 'Open in Editor' feature.
Reviewed By: fkgozali
Differential Revision: D6863932
fbshipit-source-id: d40a30271adc5c8d47149ab920e2ac11158ab756
Summary:
This makes RCTTouchHandler follow the same logic when sending touch event
coordinates as `UIManager.measure`.
This is important as UIManager.measure is used in `Touchable.js` aka the mother
of all touch events in RN.
In particular, this will make touch events correctly handled for places where RN is embedded into other screens.
Reviewed By: shergin
Differential Revision: D6838102
fbshipit-source-id: 70cad52606ea931cb637d8aa2d4845818eea0647
Summary:
So in v0.52.0 space-evenly is introduced but not yet implemented (1050e0b by woehrl01). This pull request implements the space-evenly.
Manual Testing.
![notes marker](https://i.imgur.com/IXmezVY.png)
[IOS] [FEATURE] [Yoga] Adding space-evenly on justify-content in iOS
[ANDROID] [FEATURE] [Yoga] - Adding space-evenly on justify-content in Android
Closes https://github.com/facebook/react-native/pull/17805
Differential Revision: D6858294
Pulled By: shergin
fbshipit-source-id: 7a705ca05f58603ef4588e1bfd16c16a78f8a390
Summary:
Fix issues with the react-native CLI when linking iOS and tvOS libraries to a project created with `react-native init`. (#13783)
Verified the changes against test project at https://github.com/dlowder-salesforce/react-native-link-test. Both `react-native link react-native-svg` and `react-native unlink react-native-svg` work correctly on this project. Added new unit test for the new file added to `local-cli/link/ios`.
[CLI] [BUGFIX] `react-native link` has been fixed to correctly link iOS and tvOS targets.
[IOS] [BUGFIX] `react-native link` has been fixed to correctly link iOS and tvOS targets.
Closes https://github.com/facebook/react-native/pull/17231
Differential Revision: D6837567
Pulled By: hramos
fbshipit-source-id: 234d3d3966ae1b89cd16a37c95d303553f7ba5f5
Summary: It's been more than two years; I think everyone already migrated and learned the new behavior.
Reviewed By: emilsjolander
Differential Revision: D6829885
fbshipit-source-id: a86d56fb7235a137e9ce6e360d7ae2224b047313
Summary:
[this commit](2e1707d0e6) which was just a small refactor broke refreshControl behavior - if we render FlatList with refreshing=true, the refreshControl won't be visible on initial render.
The problem is, the [previous beginRefreshing method](2e1707d0e6 (diff-cfafa8d7e42ab87ab863f917e187a4aeL51)) was renamed to `beginRefreshingProgramatically` and the old call was left in one place [here](2e1707d0e6 (diff-cfafa8d7e42ab87ab863f917e187a4aeR47)).
Now, I am not sure what kind of jumping the mentioned commit was fixing, but since this fix only concerns the initial render, I believe it will not influence the jumping fix.
I have tested this locally in my app, can provide a video if needed.
none
[IOS] [BUGFIX] [RefreshControl] - Make sure refreshControl shows up on initial render if specified
Closes https://github.com/facebook/react-native/pull/17727
Differential Revision: D6827402
Pulled By: shergin
fbshipit-source-id: 25849244e87af54f25d636b6ade7adcf88958980
Summary:
This is a complete rewrite of RCTText, the part of React Native which manages Text and TextInput components.
Key points:
* It's understandable now. It follows a simple architectural pattern, and it's easy to debug and iterate. Text flow layout is a first-class citizen in React Native layout system now, not just a wired special case. It also brings entirely new possibilities such as nested interleaving <Text> and <View> components.
* All <Text>-specific APIs were removed from UIManager and co (it's about ~16 public methods which were used exclusively only by <Text>).
* It relies on new Yoga measurement/cloning API and on-dirty handler. So, it removes built-in dirty propagation subsystem from RN completely.
* It caches string fragments properly and granularly on a per-node basis which makes updating text-containing components more performant.
* It does not instantiate UIView for virtual components which reduces memory utilization.
* It drastically improves <TextInput> capabilities (e.g. rich text inside single line <TextInput> is now supported).
Screenshots:
https://cl.ly/2j3r1V0L0324https://cl.ly/3N2V3C3d3q3R
Reviewed By: mmmulani
Differential Revision: D6617326
fbshipit-source-id: 35d4d81b35c9870e9557d0211c0e934e6072a41e
Summary:
Builds off of cae7179c94
- Make the prop a dictionary for more configuration options
- Rename `maintainPositionAtOrBeyondIndex` -> `maintainVisibleContentPosition` + `minIndexForVisible`
- Add autoscroll threshold feature
Given the async native of RN JS and background layout, there is no way to trigger the scrollTo from JS without risking a delay, so we add the feature in native code.
== Test Plan ==
ScrollViewExample:
https://youtu.be/pmY8pxC9PRs
Reviewed By: shergin
Differential Revision: D6729160
fbshipit-source-id: 70f9bae460ce84567857a4f696da78ce9b3b834c
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