Summary:
RCTSurface instance represents React Native-powered piece of a user interface
which can be a full-screen app, separate modal view controller,
or even small widget. It is called "Surface".
The RCTSurface instance is completely thread-safe by design;
it can be created on any thread, and any its method can be called from
any thread (if the opposite is not mentioned explicitly).
The primary goals of the RCTSurface are:
- ability to measure and layout the surface in a thread-safe and synchronous manner;
- ability to create a UIView instance on demand (later);
- ability to communicate the current stage of the surface granularly.
Differential Revision: D6202576
fbshipit-source-id: 8e644c87fcaad2b6a9c9304b58384d7192747556
Summary: This logic was decoupled from RCTRootView to make it reusable.
Reviewed By: javache
Differential Revision: D6214785
fbshipit-source-id: e7419be03ba0e20d95b47c11e41789636aa6e916
Summary:
Queues Problem Intro:
UIManager queue is special queue because it has special relationship with
the Main queue.
This particular relationship comes from two key factors:
1. UIManager initiates execution of many blocks on the Main queue;
2. In some cases, we want to initiate (and wait for) some UIManager's work *synchronously* from
the Main queue.
So, how can we meet these criteria?
"Pseudo UIManager queue" comes to rescue!
"Pseudo UIManager queue" means safe execution of typical UIManager's work
on the Main queue while the UIManager queue is explicitly blocked for preventing
simultaneous/concurrent memory access.
So, how can we technically do this?
1. `RCTAssertUIManagerQueue` is okay with execution on both actual UIManager and
Pseudo UIManager queues.
2. Both `RCTExecuteOnUIManagerQueue` and `RCTUnsafeExecuteOnUIManagerQueueSync`
execute given block *synchronously* if they were called on actual UIManager
or Pseudo UIManager queues.
3. `RCTExecuteOnMainQueue` executes given block *synchronously* if we already on
the Main queue.
4. `RCTUnsafeExecuteOnUIManagerQueueSync` is smart enough to do the trick:
It detects calling on the Main queue and in this case, instead of doing
trivial *synchronous* dispatch, it does:
- Block the Main queue;
- Dispatch the special block on UIManager queue to block the queue and
concurrent memory access;
- Execute the given block on the Main queue;
- Unblock the UIManager queue.
Imagine the analogy: We have two queues: the Main one and UIManager one.
And these queues are two lanes of railway go in parallel. Then,
at some point, we merge UIManager lane with the Main lane, and all cars use
the unified the Main lane.
And then we split lanes again.
This solution assumes that the code running on UIManager queue will never
*explicitly* block the Main queue via calling `RCTUnsafeExecuteOnMainQueueSync`.
Otherwise, it can cause a deadlock.
Reviewed By: mmmulani
Differential Revision: D5935464
fbshipit-source-id: 6a60ff236280d825b4e2b101f06222266097b97f
Summary:
This is pretty normal and harmless case, we should not crash here.
I plan to refactor similar places in this file soon.
Reviewed By: AaaChiuuu
Differential Revision: D5983443
fbshipit-source-id: 922fea8ed12ebef45d249f16739aa81fe3254f19
Summary:
If you are a product developer and you need to fix your app's issues related to iPhone X limitations asap,
you can temporary use `DeviceInfo.isIPhoneX_deprecated`.
You can, but you should not. Please consider use new <SafeAreaView>.
This prop was initially named so ugly because we are trying to discourage the community to use it.
However, we understand that sometimes we need a "band-aid" to prevent our apps bleeding.
Note: This prop (DeviceInfo.isIPhoneX_deprecated) will be removed completely after 06/18.
Reviewed By: fkgozali
Differential Revision: D5946329
fbshipit-source-id: 5d6dcaf0e2d175327d59cde4b5ec2e01cd77ec70
Summary:
Reasons:
* It is more clear and readable;
* It is more semantical;
* It allows us to add some magic (and complexity, to be fair) to the RCTExecuteOnUIManagerQueue. (See next diffs in the stack.)
Reviewed By: javache
Differential Revision: D5935466
fbshipit-source-id: aeb18d6e11c047eb19182a656da581b6ce073602
Summary:
This fixes [#15801](https://github.com/facebook/react-native/issues/15801)
We ran into a strange crash on iOS (debug only). After removing the clutter I was able to reproduce it in a tiny app. You can check it out [here.](https://github.com/simonracz/textinput_stress)
The UI in JS and native are not always in sync (which is okay). Due to this, a native view might call back into JS, which is no longer present in the shadow view hierarchy there. I think this should be also okay.
TextInput in some cases calls into [setIntrinsicContentView](6d67e2dbbc/React/Modules/RCTUIManager.m (L382)), where it triggers an overly enthusiastic `NSAssert` and crashes the app.
Check out [textinput_stress](https://github.com/simonracz/textinput_stress)
Rotate the simulator a few times to see the crash or the lack of crash.
Closes https://github.com/facebook/react-native/pull/16170
Differential Revision: D5959776
Pulled By: shergin
fbshipit-source-id: f39f5a3f1d86b330ecf7cbccd90871bc01fd69d9
Summary:
This is required for D5874536, wherein I'll be introducing direction-aware props for borders.
When a view's border changes due to a direction update, only the frames of its children update. Therefore, only the children `UIView`s get a chance to be re-rendered. This is incorrect because the view that's had its borders changed also needs to re-render. So, I keep a track of the layout direction in a property on all shadow views. Then, when I update that prop within `applyLayoutNode`, I push shadow views into the `viewsWithNewFrames` set.
Reviewed By: mmmulani
Differential Revision: D5944488
fbshipit-source-id: 3f23e9973f3555612920703cdb6cec38e6360d2d
Summary: Because `RCTUIManager` is already overcomplicated and that stuff deserves separate file and header.
Reviewed By: javache
Differential Revision: D5856653
fbshipit-source-id: 7001bb8ba611976bf3b82d6a25f5619810a35b34
Summary: As per the comment, <Modal> uses entering/leaving the view hierarchy as a cue to show/hide the modal. By re-adding it, we are causing a bunch of confusion.
Reviewed By: shergin
Differential Revision: D5893607
fbshipit-source-id: ecd05799751a9bba843998ae93f24fe35edca8b4
Summary:
In some cases we need a way to specify some environmental data to shadow view
to improve layout (or do something similar), so `localData` serves these needs.
For example, any stateful embedded native views may benefit from this.
Have in mind that this data is not supposed to interfere with the state of
the shadow view.
Reviewed By: mmmulani
Differential Revision: D5884711
fbshipit-source-id: f0bf66e4608894ec4479b8aca262afcfba6b9f4b
Summary:
This should be much more performant (and it better illustrates the intension of the code).
The fix was suggested by Adlai-Holler.
Reviewed By: mmmulani
Differential Revision: D5851595
fbshipit-source-id: 45d172a5fa796549c6dcea8f35c5cbb2a4c2d2e0
Summary:
iOS 11 now requires this to be accessed on the main thread.
I think this is causing tests to fail, as the Main Thread Checker is turned on there.
Reviewed By: javache
Differential Revision: D5826570
fbshipit-source-id: 6acb7174c756a2ad657602f14c666f71b1ee8fe9
Summary:
We have to have a way to track ownership of shadow view.
Previous solution with traversing the hierarchy to figure out the root view does not actually work in some cases when the view is temporary detached from hierarchy.
This is also how it work on Andorid.
Reviewed By: mmmulani
Differential Revision: D5686112
fbshipit-source-id: a23a10e8c29c7572ac69403289db136c9d5176a9
Summary:
On an iPhone running iOS 10.3.3, I'm not seeing the UIContentSizeCategoryDidChangeNotification fire when changing the system's font scale setting. Registering for the event on `nil` instead of on the application object fixes the issue.
**Test Plan**
Verified that text in an RN app changes size when you change the system's font scale setting (Settings -> General -> Accessibility -> Larger Text). By default, RN text is supposed to scale with the system setting.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15522
Differential Revision: D5657449
Pulled By: shergin
fbshipit-source-id: d7a6a730c5cd6eb3833274a1f2029663ad3a7ad2
Summary:
Here, `reactTag` is an `NSNumber *` which uses `%@` as the format specifier. Newer versions of clang can warn or error on this. This change prevents that from happening.
See also #15402
Local builds with clang 5.
Closes https://github.com/facebook/react-native/pull/15414
Differential Revision: D5583703
Pulled By: javache
fbshipit-source-id: a6d0d2246725cd096b1f3cd062ab5924740ab76c
Summary:
**Motivation**
This is a re-worked version of #14260, by shergin's suggestion.
For iOS, if you want to inherit from a native ViewManagers, your custom ViewManager will not automatically export the parents' props. So the only way to do this today, is to basically copy/paste the parent ViewManager-file, and add your own custom logic.
With this PR, this is made more extensible by exporting the `baseModuleName` (i.e. the iOS `superclass` of the ViewManager), and then using that value to re-establish the inheritance relationship in `requireNativeComponent`.
**Test plan**
I've run this with a test project, and it works fine there. But needs more testing.
Opened this PR as [per shergin's suggestion](https://github.com/facebook/react-native/pull/10946#issuecomment-311860545) though, so we can discuss approach.
**Discussion**
* Android already supports inheritance, so this change should be compatible with that. But, not every prop available on `UIManager.RCTView.NativeProps` is actually exported by every ViewManager. So should `UIManager.RCTView.NativeProps` still be merged with `viewConfig.NativeProps`, even if the individual ViewManager does not export/use them to begin with?
* Does this break other platforms? [UWP](https://github.com/Microsoft/react-native-windows)?
Closes https://github.com/facebook/react-native/pull/14775
Differential Revision: D5392953
Pulled By: shergin
fbshipit-source-id: 5212da616acfba50cc285e2997d183cf8b2cd09f
Summary:
Fixed the test script to properly setup our third-party deps and tweaked the third-party specs a bit so they work correctly.
This currently works for projects using static libraries, but fails when using dynamic libraries (`--use-libraries`)
cc mhorowitz alloy
Closes https://github.com/facebook/react-native/pull/14100
Differential Revision: D5380728
Pulled By: javache
fbshipit-source-id: e78b6bd4466ebf2bf30b7e361eff10ec14b36a55
Summary:
This diff fixes a possibly inconsistent state of view hierarchy caused by async delayed deleting manipulation on UIView's tree.
Even if new approach may seem tricky, the previous one was just terribly wrong.
Reviewed By: javache
Differential Revision: D5374670
fbshipit-source-id: 36f27330aa8b0e4e00fe43739afe3bc6a8602e30
Summary:
Apple TV compilation is currently broken in master -- this fixes it.
Existing tests will pass after this change.
Closes https://github.com/facebook/react-native/pull/14652
Differential Revision: D5295021
Pulled By: javache
fbshipit-source-id: 8b4b0db0afa1caeacac0ad01abbed80fa7e39738
Summary:
Fix this crash by making sure the RCTDeviceInfo is doing things on the main thread.
This fixes#14043.
Reviewed By: ashwinb
Differential Revision: D5286746
fbshipit-source-id: cce3426a6e7e7221cff82f8bca663d9a060dd358
Summary:
This change introduces some APIs that are useful for making announcements through the screen reader on iOS:
- `announceForAccessibility`: The screen reader announces the string that is passed in.
- `announcementFinished`: An event that fires when the screen reader has finished making an announcement.
You can already solve similar problems with RN Android using the `accessibilityLiveRegion` prop. Live regions are a different feature but they can be used to solve the same problem. This commit does not attempt to add live region support in RN iOS because Apple did not build live region support into iOS.
Verified that `announceForAccessibility` causes VoiceOver to announce the string when VoiceOver is enabled. Verified that `announcementFinished` fires with the appropriate data in the event object. Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14168
Differential Revision: D5137004
Pulled By: javache
fbshipit-source-id: b3c10f3dfc716430a16fcc98e1bb6fe52cabd6a5
Summary:
This change introduces an API, `setAccessibilityFocus`, which moves the screen reader's focus to the passed in element. This causes VoiceOver to announce the element and draw a focus rectangle around it.
Similar functionality is already available in RN Android through the `sendAccessibilityEvent` method. Here's an example of what exists today in RN Android:
```
RCTUIManager.sendAccessibilityEvent(
node,
8 /* TYPE_VIEW_FOCUSED */);
```
Called `setAccessibilityFocus` on a couple of elements to verify that focus does indeed move when VoiceOver is enabled. Additionally, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14169
Differential Revision: D5137002
Pulled By: javache
fbshipit-source-id: 466e8b187e625de7c0f0d36e0400327dcd8d192a
Summary:
Apps commonly provide their own rage-shake menus or behaviors, including in dev builds where the dev menu is enabled on shake. Rather than try to override these settings via native code, it can be helpful to let the app define when to show the menu via the bridge.
See recent discussion in https://github.com/facebook/react-native/issues/1054
Closes https://github.com/facebook/react-native/pull/13563
Differential Revision: D4928745
Pulled By: javache
fbshipit-source-id: a5b30e1b198780bb560e1a6d528f727b3b7d4cb7
Summary:
There was no easy way to pull up the dev menu in the tvOS simulator
Run the UIExplorer demo and press cmd+d to bring up the menu
Closes https://github.com/facebook/react-native/pull/13584
Differential Revision: D4916967
Pulled By: javache
fbshipit-source-id: 27f50031f65f35dad46ad5ade7b52c7d350b31a2
Summary:
Motivation: Similar to https://github.com/facebook/react-native/pull/13242 - the application will crash with `[NSNull lastPathComponent]: unrecognized selector sent to instance` if a stack frame with no filename makes it to RCTRedBox.
Closes https://github.com/facebook/react-native/pull/13360
Differential Revision: D4848980
Pulled By: javache
fbshipit-source-id: dc506f2ba39c2d4d68982b56a6e765a19dc048b0
Summary:
Pair `reactWillMakeFirstResponder` and `reactDidMakeFirstResponder` was replaced with just `reactFocus` method
which is supposed to incapsulate all "focus" and "focus-later-if-needed" functionality.
Reviewed By: mmmulani
Differential Revision: D4664626
fbshipit-source-id: 8d3b7935ca26d32ba1d1826a585cce0396fcc885
Summary:
…th RCTSharedApplication()
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
Using React Native latest version with Cocoapods 1.2.0 causes the following error inside iOS app extensions
> /react-native/React/Modules/RCTAccessibilityManager.m:67:70: ‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
Moving the use of [UIApplication sharedApplication] to RCTSharedApplication() which is safe on app extension
- [ ] Provide a **test plan** demonstrating that the code is solid.
I am not sure how to test such that all the features which touch the modified code are tested.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
Using React Native latest v
Closes https://github.com/facebook/react-native/pull/13227
Differential Revision: D4816338
Pulled By: javache
fbshipit-source-id: e3e3c77882990ad1817b0b633521cff52571ecd0
Summary:
This fixes a bug that causes properties to keep stale values because they were not restored to their default after being removed when their value was controlled by native animated.
To fix this we restore default values in `disconnectFromView` by updating views with null values for all props that we modified previously. However this causes another issue where we lose any props that were set by the normal process because NativeAnimated operations are always executed after UIManager operatations. To fix this I added a way to hook into UIManager view updating process to be able to execute NativeAnimated operations either before or after updating native views.
In the case of disconnecting we want to do it before updating views so that it does: Value changed by native animated -> value restored to default -> (optional) value updated by normal prop.
This PR also depends on #10658.
**Test plan**
Tested that this fixed a particular bug in an app that uses ex-navigation + native animations where a navbar w
Closes https://github.com/facebook/react-native/pull/11819
Differential Revision: D4752566
Pulled By: javache
fbshipit-source-id: 68ee28200ffeba859ae1b98ac753bd7dcb8910f0
Summary:
Various fixes of xcode projects and cleaning up some warnings
Closes https://github.com/facebook/react-native/pull/13109
Differential Revision: D4762652
Pulled By: lacker
fbshipit-source-id: b452976a58962439de4adecc8e703264af40cb38
Summary:
Motivation: Fixes Xcode warning `Ivar '_websocketExecutorName' which backs the property is not referenced in this property's accessor` which shows up because this property has no setter (and is never set anywhere).
Closes https://github.com/facebook/react-native/pull/12639
Differential Revision: D4745437
Pulled By: javache
fbshipit-source-id: 3ab4b0df62f90adc2b62d891197dc783e07da4e3
Summary:
While working with `RCTEventEmitter` I noticed that if an event is emitted before `_listenerCount` is updated, it will not go through because the listeners count hasn't been updated. Moving the count update before the invokation of `startObserving` and `stopObserving` fixes the issue. Same way if you remove the last listener and an event is fired before the count is updated (while it shouldn't be fired).
**Test plan (required)**
An easy test to demonstrate it is to implement `startObserving` to synchronously fire an event. Without the change, a warning is thrown, with the change, the event is fired. Not very strong on Obj-C here and I didn't know how to mock out the native stuff. Would be glad to write a failing unit test tho :)
Closes https://github.com/facebook/react-native/pull/11907
Differential Revision: D4738965
Pulled By: javache
fbshipit-source-id: cf175051be5b9c5de761d3dcd290560e1639b05e
Summary:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The PR #11613 (0.43) removed this missing `toggleElementInspector` event send when `jsLoaded` in DevMenu (Now is DevSettings), it should open the inspector if `isElementInspectorShown` is true when we reload JS.
The dev menu text `Show / Hide Inspector` is dependent on `isElementInspectorShown` bool value.
([This behavior in 0.42](https://github.com/facebook/react-native/blob/0.42-stable/React/Modules/RCTDevMenu.mm#L436-L442))
Manual testing in UIExplorer:
* Open the dev menu and click `Show Inspector`
* Open the dev menu and click `Reload JS`
* The built-in inspector should keep open (dev menu text: `Hide Inspector`)
Closes https://github.com/facebook/react-native/pull/12999
Differential Revision: D4738959
Pulled By: javache
fbshipit-source-id: b3f584db51aa0e1b463c52003967b00bcd81bc99
Summary:
Several things:
* The mess with insets was fixed. Previously we tried to compensate the insets difference with `UITextField` by adjusting `textContainerInset` property, moreover we delegated negative part of this compensation to the view inset. That was terrible because it breaks `contentSize` computation, complicates whole insets consept, complicates everything; it just was not right. Now we are fixing the top and left inset differences in different places. We disable left and right 5pt margin by setting `_textView.textContainer.lineFragmentPadding = 0` and we introduce top 5px inset as a DEFAULT value for top inset for common multiline <TextInput> (this value can be easilly overwritten in Javascript).
* Internal layout and contentSize computations were unified and simplified.
* Now we report `intrinsicContentSize` value to Yoga, one step before auto-expandable TextInput.
Depends on D4640207.
Reviewed By: mmmulani
Differential Revision: D4645921
fbshipit-source-id: da5988ebac50be967caecd71e780c014f6eb257a
Summary:
The `UIManager` already has a lot of responsibilities and is deeply
tied with React Native's view architecture. This diff separates out a
`DeviceInfo` native module to provide information about screen dimensions and
font scale, etc.
Reviewed By: fkgozali
Differential Revision: D4713834
fbshipit-source-id: f2ee93acf876a4221c29a8c731f5abeffbb97974
Summary:
Moving setting `availableSize` for `RCTRootShadowView` on earlier stage allows to prevent situations where `availableSize` is not specified yet, but Yoga layout is already happening.
Because `availableSize` equals {infinity, infinity} by default (in this case), Yoga returns a lot of nodes with infinit metrics, which confises UIKit.
Reviewed By: mmmulani
Differential Revision: D4672170
fbshipit-source-id: f9d8c84799dcbdb6b9230ddef6284d84df268833
Summary:
A related Android PR is #11008.
Font scale was exposed through:
- The `getContentSizeMultiplier` method
- The `didUpdateContentSizeMultiplier` event
These are now deprecated. The reason is that there was already an API that exposed font scale. However, it was Android only. We now expose font scale through that API on iOS as well. Specifically:
- Font scale is now available as `PixelRatio.getFontScale()`.
- The `change` event on the `Dimensions` object now fires when font scale changes.
This change also adds support for `Dimensions.get('screen')` on iOS. Previously, only `Dimensions.get('window')` was available on iOS. The motivation is that, [according to this comment](https://github.com/facebook/react-native/pull/11008#issuecomment-275123609), we'd like to deprecate `window` dimensions in favor of `screen` dimensions in the future.
**Test plan (required)**
Verified that `PixelRatio.getFontScale()` and the `change` event work properly in a test app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12268
Differential Revision: D4673642
Pulled By: mkonicek
fbshipit-source-id: 2602204da6998a96216e06f5321f28f6603e4972
Summary: RCTDevSettings incorrectly assigned "bad" executor-override class to the executor instead of checking if the class exists before assigning it. It should really check if the class exists, and fallback to defaults otherwise.
Reviewed By: mmmulani, yungsters
Differential Revision: D4655926
fbshipit-source-id: 48c8fe28f22aaa8430752411ce5e6e858dbd4b32
Summary:
* The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability.
It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development.
* I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec.
Closes https://github.com/facebook/react-native/pull/12602
Differential Revision: D4621021
Pulled By: ericvicenti
fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
Summary:
Nothing actually changed except the deprecation.
Existed `intrinsicSize` was already implemented as `intrinsicContentSize` and this change only removes redundancy.
Moreover, we do not need `rootViewDidChangeIntrinsicSize` delegate method anymore; this is now mentioned in its description.
Depends on D4577890
Reviewed By: mmmulani
Differential Revision: D4589344
fbshipit-source-id: 16ed62cbf6bf72678bd7f7c11d4812c5aa36c743
Summary:
This decouples non-UI logic from RCTDevMenu into a new module RCTDevSettings.
**Motivation**: This allows developers to change dev settings without depending on the built-in dev menu, e.g. if they want to introduce their own UI, or have other devtools logic that doesn't depend on an action sheet.
It also introduces the RCTDevSettingsDataSource protocol for storing dev tools preferences. This could allow a developer to implement alternative behaviors, e.g. loading the settings from some other config, changing settings based on the user, deciding not to persist some settings, or something else.
The included data source implementation, RCTDevSettingsUserDefaultsDataSource, uses NSUserDefaults and is backwards compatible with the older implementation, so **no workflows or dependent code will break, and old saved settings will persist.**
The RCTDevMenu interface has not changed and is therefore also backwards-compatible, though
some methods are now deprecated.
In order to ensure that RCTDevSettings
Closes https://github.com/facebook/react-native/pull/11613
Reviewed By: mmmulani
Differential Revision: D4571773
Pulled By: javache
fbshipit-source-id: 25555d0a6eaa81f694343e079ed02439e5845fbc
Summary:
Now things look much more clear, I hope.
This diff:
* Introduces new property of `RCTRootShadowView` `availableSize` which represents exactly what we transmit to layout engine;
* Illuminates conflict between logical `availableSize` and explicitly specified size of DOM node (current `size`);
* Splits overcomplicated `setSize:forView:` method into two unrelated ones;
* Changes actual values of `RCTRootViewSizeFlexibility` enum constants for simpler usage;
* Completely removes `sizeFlexibility` concept from `RCTRootShadowView` (in favor of special values of `availableSize`);
* Makes the code clearer finally.
This is beginning of big effort to improve `RCTRootView` and co.
Reviewed By: mmmulani
Differential Revision: D4562834
fbshipit-source-id: f5baaf2859ea430d44645a6b5d35f222f15a668e
Summary:
Motivation:
* `RCTShadowView`'s `frame` property actually represents computed layout of the view. We must not use it as a setter for yoga node styles;
* Using `frame` and `setLeftTop` in existing way actually works only for view with absolute positioning, so it is super rare and special case;
* Internally, setting `frame` only make sense to `RootView`, and in that case there we always must not change `origin` we are introducing `setSize` method.
Changes:
* `[-RCTShadowView setFrame:]` was removed, `frame` property is readonly now;
* `[-RCTShadowView setLeftTop:]` was removed; no replacement provided;
* `[-RCTShadowView size]` read-write property was added;
* `[-RCTUIManager setFrame:forView:]` was deprecated, use (just introduced) `setSize:forView:` instead;
* `[-RCTUIManager setSize:forView:]` was added.
If you are still need some of removed methods, you are probably doing something wrong. Consider using `setIntrinsicContentSize`-family methods,
`setSize`-family methods, or (in the worst case) accessing `yogaNode` directly.
Reviewed By: javache
Differential Revision: D4491384
fbshipit-source-id: 56dd84567324c5a86e4c870a41c38322dc1224d2
Yujie Liu
Valentin Shergin
Ramanpreet Nara
Dmitry Zakharov
Adam Ernst
Alex Dvornikov
Frank Manns
Simon Racz
Jason Carreiro
Mehdi Mulani
Jakub Grzmiel
Brian Vaughn
Ben Nham
Paco Estevez Garcia
Adam Comella
Rafael Oleza
Dave Lee
Pieter De Baets
Nurzhan Bakibayev
Pieter De Baets
Yu Wang
Christian Brevik
dlowder-salesforce
Theo Yaung
Adam Comella
William Schurman
Connor McEwen
Emily Janzer
Marc Horowitz
Ben Roth
Shruti Malugu
Janic Duplessis
Daniele Conti
Jhen
Ashwin Bharambe
Kevin Gozali
Eloy Durán
Lukas Piatkowski
Mathieu Baudet
