Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
This refined algorithm now takes a zoom/scale into account and deals with `contentInset` properly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22382482
fbshipit-source-id: 7e9d34d3bababf68e624c045c308957e7e5c9d84
Summary:
Changelog: [Internal]
When JS Inspector is activated, ScrollView is unmounted and then mounted again with same state.
ScrollView's content offset was being set to 0 inside `[RCTScrollViewComponentView prepareForRecycle]` during unmount but when it is mounted again, we ignored value inside state.
Reviewed By: shergin
Differential Revision: D22333125
fbshipit-source-id: f232dc95b695605f4819f29d8e0bf14b2f3e9150
Summary:
This is the first implementation stage of on-demand child views mounting for <ScrollView> feature.
It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area.
Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling.
This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304012
fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary:
Changelog: [Internal]
# Problem
`scrollView.state.contentOffset` was not in sync with actual `contentOffset` in case `contentOffset` is changed programatically.
# Solution
Add a flag `_isUserTriggeredScrolling` that indicates whether the current scroll is triggered by user or not. In case it isn't, update state.
Reviewed By: shergin
Differential Revision: D20098161
fbshipit-source-id: 021d916e7a45a24095a47bb8f84d1102226b672a
Summary:
This diff re-enables propagation of ScrollView's content-offset value down to the ShadowTree layer and enables measure fucntions opt-in incorporating this info to result.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: zackargyle
Differential Revision: D18981891
fbshipit-source-id: a6c0f4e690703b0ee07d45efab161750cfcc4b60
Summary:
UIScrollView sometimes calls its delegate during its own deallocation and that causes a crash. This change introducing nil-ing the delegate before the deallocation to prevent this.
We already had this implemented in D17924429 but D18752886 broke that. This diff fixes that one more time.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18933934
fbshipit-source-id: 8da22ff4b1fefee712ced25cf0f1c239535554da
Summary:
This diff disables the feature that propagates ScrollView's content offset to ShadowNode hierarchy making measuring content-offset-aware.
Seems that feature breaks FlatList because it does not expect measure calls to be content-offset-aware. We need to validate which legacy `measure*` calls should be content-offset-aware and which should not, and then verify that actual feature works (it's not clear why it worked with FlatList before) well before re-enabling this.
For now, the most safer choice is to disable this feature because I don't think some call sites actually rely on it now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18777939
fbshipit-source-id: 20d6c1081e7d2cc3b5a7a172ed947a9ae9cdfaab
Summary:
This diff moves the delegate splitter from RCTScrollViewComponentView class to RCTEnhancedScrollView. Now, it's a key feature of RCTEnhancedScrollView.
We need this to make `delegate` property of our UIScrollView subclass as resilient to any abuse as possible. E.g., if some other part of the app, unrelated to RN (e.g. BottomSheet component), nils the property, all dependent RN specific infra should continue to work. To make it possible, we make an exposed property to use the internal delegate splitter instead of providing direct access to the property of a superclass.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18752886
fbshipit-source-id: 04ec4758afefb8e17481d69471d53c61ab396698
Summary:
* Previously we called `onScrollEndDrag` in `scrollViewWillEndDragging` which was not correct.
* Now we also call `_updateStateWithContentOffset` in the method to update the stored in state `contentOffset`. This fixes all `measure*` infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18563050
fbshipit-source-id: ade696eda579642c22927c8a56ff122cd61a7534
Summary:
ScrollView isn't using codegen, therefore we need to manually write commands interface. I also typed commands so it uses `Double` instead of `number`.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18371887
fbshipit-source-id: 3bd11b9969b80ce6d2302e2f0da28884e9221b7e
Summary:
Seems a ScrollView sometimes calls the delegate in own destructor; and seems that in some configurations the delegate is also already destroyed at this point. I am not sure if this a bug in UIKit or not, but seems the fix is easy, we just have to clear the ScrollView's delegate on the delegate's deallocation.
This issue is also looks similar:
https://stackoverflow.com/questions/18778691/crash-on-exc-breakpoint-scroll-view/19011871
Changelog: [iOS] [Fixed] - Fixed crash in RCTScrollViewComponentView
Reviewed By: sammy-SC
Differential Revision: D17924429
fbshipit-source-id: 5727bca9f028e28f76f60304c187ee39eb6e1856
Summary: To enable onScroll animations with Fabric's scrollView on iOS, we dispatch onScroll event to Paper's eventDispatcher as well as to Fabric's one. One we have a proper NativeAnimationDriver in place, we will get rid of this.
Reviewed By: shergin
Differential Revision: D17814260
fbshipit-source-id: f04faf59cdfd4ea5cede513388e30500b4cb2ad5
Summary:
Setting minimal throttle to 1/60 causes dropped updates.
Let's take following example
Each frame is 16.666 MS.
Frame1: [________didScroll is called towards end of the frame_]
Frame2: [_didScroll is called towards beginning of the frame_________]
update from Frame 2 doesn't propagate because we set throttle to 16MS thinking that `onScroll` is called for each frame.
If Javascript specified value below 1/60 it is basically asking for every update.
Reviewed By: shergin, mdvacca
Differential Revision: D17829926
fbshipit-source-id: e7b07fd09581cd5053aa27a62cf6f6ddb2193783
Summary: `_state` should be cleaned up in `prepareForRecycle` as this could potentially cause undesired initial render of the component.
Reviewed By: shergin
Differential Revision: D17628152
fbshipit-source-id: 0116954ab7a5b2f17099db6d9ec47c8568cae8b0
Summary:
Seems a ScrollView sometimes calls the delegate in own destructor; and seems that in some configurations the delegate is also already destroyed at this point. I am not sure if this a bug in UIKit or not, but seems the fix is easy, we just have to clear the ScrollView's delegate on the delegate's deallocation.
This issue is also looks similar:
https://stackoverflow.com/questions/18778691/crash-on-exc-breakpoint-scroll-view/19011871
Reviewed By: sammy-SC
Differential Revision: D17531071
fbshipit-source-id: 373ae5270199f3a9099bda8c34b06737446858f1
Summary: This diff adds support from `ScrollView::scrollEventThrottle` property on iOS.
Reviewed By: JoshuaGross
Differential Revision: D17000397
fbshipit-source-id: 93f23919a6a2588000c0eeca869171d1036348b6
Summary: The previous rename from RCT->RN prefix ended up causing some confusions on which prefix to use for which files and under what circumstances. To avoid further confusion before we're done with the re-architecture project, let's keep them as RCT.
Reviewed By: mdvacca
Differential Revision: D16705566
fbshipit-source-id: 395bff771c84e5ded6b2261a84c7549df1e6c5e5
Summary: Fabric ObjC(++) files will be prefixed by RN* for the time being, this codemod is a simple rename. This includes `interface` and `protocol` definition
Reviewed By: PeteTheHeat, yungsters
Differential Revision: D16611524
fbshipit-source-id: 868d2571ea2414dde4cbb3b75b1334b779b5d832
Summary:
See the comment in the code.
As part of proper fix of it, we also should remove a line in RCTScrollView that nulls the delegate.
Reviewed By: mdvacca
Differential Revision: D16296050
fbshipit-source-id: 54a4c6c60de4bd97c5cfb44652b5dc26852c540c
Summary:
I finally convinced that we need to add this everywhere.
iOS internals can call those methods at any moment (which is happening in coming diffs), so we cannot predict `_eventEmitter` being not null.
Reviewed By: mdvacca
Differential Revision: D16296052
fbshipit-source-id: 34447c2b5af4117d75930d68593d60bace119bbd
Summary: We should not use `self.contentView` accessor to insert container views (views that might be used as a container for nested views) into component view otherwise it causes double applying of padding values.
Reviewed By: mdvacca
Differential Revision: D15862075
fbshipit-source-id: aad834aeca06f66b19c2f7bbaa0b58f937e66994
Summary:
In some cases, the view class is the only that retains stored `props_` variable. At the same time the `[super updateProps:props oldProps:oldProps];` actually resets the pointer with a pointer to new props value which sometimes causes the deallocation of the old value. All that is okay unless the implementation of `updateProps:oldProps:` in superclasses stores a raw reference to an old value in the very beginning of the method (for convenience and perf reasons).
So, to prevent preliminary deallocation of the old value pointed by `_props` we moved all `[super updateProps:props oldProps:oldProps];` calls to the end of overloaded methods.
Reviewed By: mdvacca
Differential Revision: D15770068
fbshipit-source-id: af36b3e70560ab00846cd26b0963bbc059e977bc
Summary: It's a antient left over which was copy pasted a dozen of times. All `RCTViewComponentView` subclasses have own copy of the old props `_props`, so it's useless to check for `oldProps`.
Reviewed By: mdvacca
Differential Revision: D15770067
fbshipit-source-id: 39f4d71ccdcf0c9a5b911b17a3b922dbe6dd9a8e
Summary: We need this only until Fabric has own command-execution pipeline.
Reviewed By: mdvacca
Differential Revision: D15501202
fbshipit-source-id: aad77660ada43e429722b13d1da2f998a1726c73
Summary:
Same as previous one but for the rest (minority) of methods.
I didn't change `updateLocalData:` because it's going away soon anyway.
Reviewed By: mdvacca
Differential Revision: D15473217
fbshipit-source-id: 6a6bd66c5343211a973fc34ad11e86efe031d07d
Summary:
Passing shared pointers as references can save us a couple of milliseconds at scale.
Originally, I didn't expect that Objective-C supports passing values by references, but apparently it does.
Reviewed By: mdvacca
Differential Revision: D15473218
fbshipit-source-id: 15eb3770cc0889654647a8e91607d8aa78010121
Summary: This way we can reuse this code in other RCTScrollViewComponentView-satellite components, especially in standard pull-to-refresh component.
Reviewed By: mdvacca
Differential Revision: D15403307
fbshipit-source-id: 5999f851f22db0f358887e1a86d610e163adcb1d
Summary:
This diff contains two changes:
* The actual UIScrollView is now mounted inside the component as `contentView` which mostly means that border-props will properly affect the layout of the scroll view (the scroll view will be laid out inside borders, not on top of those). And that also simplifies the code.
* Now the component view exposes the actual scroll view, its delegate splitter, and the container view defining a single interface for all possible integration that can be done with the Scroll View Component.
Reviewed By: mdvacca
Differential Revision: D15397283
fbshipit-source-id: 35e860b8bf55fbd4d0a5f4116f79e4507df79098
Summary: Future improvements in RCTScrollViewComponentView require ability to have multiple listeners of UIScrollViewDelegate (e.g. PullToRefresh component needs it), therefore we need a splitter to support it.
Reviewed By: JoshuaGross
Differential Revision: D15345301
fbshipit-source-id: 62bb50c4fdd4fa64ece5d7cc6ddc76367c84c4b3
Summary:
This is the final piece of change that makes measuring (`LayoutableShadowNode::getRelativeLayoutMetrics()`) take ScrollView content offset into account (on iOS).
It works pretty simply: at the end of scrolling (or zooming) action ScrollView updates the state which later can be used for computing `transform` which measuring uses to adjust values in LaoutMetrics.
Reviewed By: mdvacca
Differential Revision: D15323688
fbshipit-source-id: fdf86c6cd9bdfd56caddd4b39bdd1185760b9f94
Summary: Seems we need this now to enable future improvements in ScrollView such as correct measure, pull-to-refresh and so on.
Reviewed By: mdvacca
Differential Revision: D15323687
fbshipit-source-id: fae37431ccbbf2faec9c84752396153689b873ef
Summary:
ComponentDescriptorProvider represents unified way to create a particular descriptor.
Now all ComponentViews (which support RCTComponentViewProtocol) expose a `ComponentDescriptorProvider` which will allow creating and registering ComponentDescriptor instances for all visual components automatically as a part of ComponentView registration process.
Don't panic, everything is still being as explicit as it always was, no magic involved; we just will have only one registration step instead of two parallel.
That also opens a way to register components on the fly.
Reviewed By: JoshuaGross
Differential Revision: D14963488
fbshipit-source-id: 9e9d9166fabaf7b30b35b8647faa6e3a19cd2435
Summary: Apparently, I haven't modify all files in D14018903. Here is the last (I hope) chunk.
Reviewed By: JoshuaGross
Differential Revision: D14058288
fbshipit-source-id: b21950cdd1aa9aa55b0c72fac0f8b44e4a7d131c
Summary: The new method in the protocol enforces view component classes to expose a component handle of the component that the view component represents. That will allow us to wire up those classes with shadow views in runtime explicitly and in a much more performant way than it is now.
Reviewed By: mdvacca
Differential Revision: D13114663
fbshipit-source-id: 853187d978aab200f85719d9c1d9fea2e3ad4e55
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
* Now all `RCTViewComponentView` subclasses are required to set `_props` instance variable in the constructor with a default value;
* `RCTViewComponentView`'s `_props` instance variable now has `ShadredViewProps` type (that enforced by `static_assert` in `ConcreteViewShadowNode` template);
* New we use `static_pointer_cast` instead of `dynamic_pointer_cast` for casting props.
Reviewed By: mdvacca
Differential Revision: D9734199
fbshipit-source-id: b0a0939c936f8b5b540fa5fa1e4a2f1037346fc5
Samuel Susla
Valentin Shergin
David Vacca
Andres Suarez
Kevin Gozali
Héctor Ramos