Summary:
@public
This is quite a big diff but the actual meaningful change is simple: now we use ShadowView class instead of ShadowNode in mutation instructions.
Note:
* In some places (especially during diffing) we have to operate with ShadowNodeViewPair objects (which represents a pair of ShadowNode and ShadowView). The reason for that is that we cannot construct child ShadowViews from parent ShadowViews because they don't have any information about children.
* `ShadowTree::emitLayoutEvents` is now much simpler because ShadowView better represents the specifics of this kind of object.
* The code in RCTMountingManager also became simpler.
This change will allow us to implement more cool tricks soon.
Reviewed By: mdvacca
Differential Revision: D9403564
fbshipit-source-id: dbc7c61af250144d6c7335a01dc30df0005559a2
Summary:
@public
MessageQueueEventBeat implements particular Event Beat synchronized with Message Queue and calling a callback on the JS thread (aka Message Queue thread). The actual beat is synchronized with the main run loop.
Reviewed By: mdvacca
Differential Revision: D8886230
fbshipit-source-id: 97ef7d10f705789b4b0cd3a12389db960159f289
Summary:
@public
EventBeat is an abstraction around proper event scheduling combining proper timing and proper threading. Event Queues use Event Beat to ensure that events are delivered on proper threads and in proper timing (probably batched). Consumers can `request` the next beat and `induce` immediatly beat.
MainRunLoopEventBeat implements particular Event Beat synchronized with the main event loop and calling a callback on the main thread.
Reviewed By: mdvacca
Differential Revision: D8886229
fbshipit-source-id: 1a42fcbf4cd61c6cb4c502890566c98b00226f31
Summary:
@public
We are moving away from using `RCTBridge` instance in public APIs to enable us using more performance solutions in the future.
This change also fixes "SwipeBack issue" caused by RCTSurfaceHostingProxyRootView returning nil bridge.
Reviewed By: mdvacca
Differential Revision: D9094625
fbshipit-source-id: 6bde3c54773e75ca4c0b6fd908da9d7235b5c3be
Summary:
@public
We need that because gonna add much more event-related stuff, so it deserves separate buck target.
Reviewed By: mdvacca
Differential Revision: D8831547
fbshipit-source-id: 616581b39b425a49302d5f7f86267e62b0d58389
Summary:
@public
This diff consists of many interdependent changes which support one simple idea: YogaLayoutableShadowNode is now using YGNode children to iterate on them (it previously relied on `ShadowNode::getChildren()`). All other changes are just an unavoidable consequence of that. Hence we don't need to filter child nodes every single time when we do layout anymore! The logic around `clone callback` is also drastically simpler now.
The new approach also implies that `LayoutableShadowNode` and `YogaLayoutableShadowNode` don't use `shared_ptr`s to refer to ShadowNode objects because new relationship does not imply ownership. No more `SharedShadowNode` objects in those two classes.
Reviewed By: mdvacca
Differential Revision: D8796159
fbshipit-source-id: 6f52f92d1826f3eb13b2f8a132c3ea77de155d82
Summary:
@public
This approach is basically copying exising implementation that we have in RCTTextView (D5806097).
Changes in `AttributedString` is quite trivial.
Reviewed By: mdvacca
Differential Revision: D8740000
fbshipit-source-id: 276afdf93d777f7ccb99ca8ee5a18a880de2acbf
Summary:
@public
Everything is better with C++ templates.
In this cases templates allow us to remove additional parameters and casts on the callsite.
Reviewed By: mdvacca
Differential Revision: D8754523
fbshipit-source-id: 2340b2cd96ab0a60d54d9aa30dea3c072b951a8a
Summary:
@public
We have this feature in the current version of RN, so it would be nice to support that in Fabric as well. This should save us tens of ms of views creation during mounting.
And that's quite easy to do!
Reviewed By: fkgozali
Differential Revision: D8701992
fbshipit-source-id: 4e3049df009ffd65bb43043de388e81795e5e559
Summary:
@public
When some `RCTImageComponentView` is going to be recycled, it makes sense to free an associated bitmap because it will not be reused anyways.
Reviewed By: mdvacca
Differential Revision: D8601751
fbshipit-source-id: 1318622b66460b8e5588a4420c91c516fe2b1106
Summary:
@public
We have found that because of some bugs Mounting Manager can request creation of views with same tag several times (which should not happen).
Now, we can fail earlier in such cases.
Reviewed By: fkgozali
Differential Revision: D8585164
fbshipit-source-id: 63c6391de5adfe711552918a20a18396f54ec201
Summary:
@public
We need this to enable measuring, responder-chain management and another features powered by UIManager commands.
As soon we have Fabric specifc command-delivery pipeline this must be reverted.
Reviewed By: fkgozali
Differential Revision: D8552360
fbshipit-source-id: d56e12d38c32d8ad98cb230671bac1f35e87e647
Summary:
@public
For now we only support trivial uniformed (all sides are equal) border rendering (which can be direclty mapped to CALayer features).
Support of the more complex and fancy borders is comming soon.
Reviewed By: mdvacca
Differential Revision: D8528923
fbshipit-source-id: 0883cdc2b855fc63d399e1a93010f259f0628f48
Summary:
@public
Another small but important piece of Accessibility Support.
Reviewed By: mdvacca
Differential Revision: D8528921
fbshipit-source-id: d4ba87bab702d76a90e9ddb751999193243cdc74
Summary:
@public
Trivial. It's also nice this we have a default encoding now.
Reviewed By: fkgozali
Differential Revision: D8528919
fbshipit-source-id: 0853eca828f22ead1a337fea3d7a2fc9a48e84c8
Summary:
@public
This is iOS-specific implementation of <Image> view.
Not all props and features are supported yet.
Known issues:
- Animated GIFs;
- CA transitions during image appearance.
Reviewed By: mdvacca
Differential Revision: D8526570
fbshipit-source-id: a4b1dca583b139b8a09431565a79f051fae67a36
Summary:
@public
ImageManager coordinates all work related to loading image bitmaps for <Image> component.
The particular iOS implementation uses RCTImageLoader from RCTImage module under the hood.
Reviewed By: fkgozali
Differential Revision: D8526571
fbshipit-source-id: a0d927972d30113eed6e0cd169fceee17610181d
Summary:
@public
After reading about move-semantic and rvalue refs I realized that we (I) definitely overuse `auto &&` (aka universal reference) construction. Even if this is harmless, does not look good and idiomatic.
Whenever I used that from a semantical point of view I always meant "I need an alias for this" which is actually "read-only reference" which is `const auto &`.
This is also fit good to our policy where "everything is const (immutable) by default".
Hence I change that to how it should be.
Reviewed By: fkgozali
Differential Revision: D8475637
fbshipit-source-id: 0a691ededa0e798db8ffa053bff0f400913ab7b8
Summary:
@public
`ContextContainer` is general purpose DI container for Fabric.
We need this to communicate some enviroment-specific and/or platform-specific modules down to cross-platform C++ code.
The first one will be ImageManager. Soon.
Reviewed By: fkgozali
Differential Revision: D8475636
fbshipit-source-id: 0afc65063f818d0bab736cd2c55c6fdd21b629ac
Summary:
@public
... and we initalize this in Surface.
We need this for requesting images with proper size/pixel-density, setup proper parameters for rasterizing CALayer's and rounding layout metric values.
Then we have to figure out how to wire this up with YGConfig.
Reviewed By: fkgozali
Differential Revision: D8475639
fbshipit-source-id: cec7af581b94efb4595dcf3f232252ce87a1fde3
Summary:
@public
When JS first starts up, Fabric surface end up double registering itself, causing events to not work. So let's guard it so that registration happens only on reload case.
Reviewed By: shergin
Differential Revision: D8521002
fbshipit-source-id: 441f121786e860dc10e959e940b411c2afaf96dc
Summary:
@public
The bridge may send the reload event twice when reloading JS in some rare condition. The 2nd one was actually when the "new" bridge wasn't valid yet, so log an error if that happens. This may happen if the connection to Metro server gets into a weird state. Restarting Metro would solve the problem.
The issue was that `RCTBridgeWillReloadNotification` fired twice for each reload with metro connected.
Reviewed By: mmmulani
Differential Revision: D8509448
fbshipit-source-id: 647fb98c0a97503409a10451b8f152145947ae20
Summary: After moving all matrix math to C++, the actual client native code is quite trivial.
Reviewed By: fkgozali
Differential Revision: D8344059
fbshipit-source-id: 6910c6af5de64d5f901e82075d30edbde177af40
Summary:
This is quite interesting.
In Fabric, on C++ layer we store `color` values as `SharedColor` objects which (on iOS) are `shared_ptr`s with custom deallocater (which calls CoreFramework's `CFRelease` function). All this means that we cannot directly transfer ovenership of this managed pointer to ARC (honestly, I am not 100% sure about that, but at least this "shared ownershipt between ARC and non-ARC worlds" concept is as dangerous as any "relying on implementation details" approach). To to so, we have to create a copy and transfer ownership of the copy to ARC (which we do in 1RCTCGColorRefFromSharedColor`).
Reviewed By: fkgozali
Differential Revision: D8344061
fbshipit-source-id: 8b6764e1539b1982b41f502bbd3307c7b6900fd9
Summary:
Trivial.
`nativeId` is meant to be used by subclasses of external inspector-like tools, so it does not have any real functionality.
Reviewed By: fkgozali
Differential Revision: D8344064
fbshipit-source-id: d86ef378cda1f7f0e9a7b4ffc09f51004ae530d2
Summary:
This is pretty straightforward implementation uses native `UISwitch`.
Suddenly we need Switch to test a bunch of other things.
Reviewed By: fkgozali
Differential Revision: D8344055
fbshipit-source-id: cfc51b8bc11198eb9d4d5e4745b96fb3a7f14de1
Summary:
This is just the convenient way to embed native views inside custom View components.
See coming <Switch> implementation as an example.
Reviewed By: fkgozali
Differential Revision: D8344056
fbshipit-source-id: 7f5f8cfeeffa7676bc7b562aa07f006cb9006575
Summary:
On JS reload the FabricUIManager and EventDispatcher didn't get release due to a retain cycle. This breaks the cycle.
In addition, force release the Scheduler on reload so that the stale classes get cleaned up properly, avoiding crashes. Also the surface now remounts the content correctly
Reviewed By: shergin
Differential Revision: D8414916
fbshipit-source-id: 4b14031f29b3bc9987d7aa765dc0d930a7de2b1e
Summary: The app needs to find the surface by rootTag at some point.
Reviewed By: shergin
Differential Revision: D8391957
fbshipit-source-id: b0bb107b7be882071890afb46de17b50e7ee060d
Summary:
Using `EventHandlers` name was a bad idea, and I cannot tolerate it anymore.
The worst part of it is that when you have a collection of `EventHandlers` objects you cannot use plural word to describe it because `EventHandlers` is an already plural word.
And, this object is actually an event emitter, the thing on which we call events.
Reviewed By: fkgozali
Differential Revision: D8247723
fbshipit-source-id: b3303a4b9529bd6d32bb8ca0378287ebefaedda8
Summary:
RCTSurfaceTouchHandler is a complete rewrite of RCTTouchHandler which uses direct Fabric-specific event dispatching pipeline and several new approaches to managing active events (such as high-performant C++ collections, better management of identifier pool, and so on).
Besides that, the new implementation is much more W3C compliant that it used to be (see old TODOs near `receiveTouches()` implementation in Javascript).
So, touch events work now!
Reviewed By: fkgozali
Differential Revision: D8246713
fbshipit-source-id: 218dc15cd8f982237de7e2497ff36a7bfe6d37cc
Summary: Note: Some features are not suported yet, e.g. event throttling.
Reviewed By: fkgozali
Differential Revision: D8082771
fbshipit-source-id: d60f6e9011283aeee7aff77dc9178e99f06deb5c
Summary: This also illustrates how we should use EventHandlers objects.
Reviewed By: fkgozali
Differential Revision: D8053357
fbshipit-source-id: cba084c8a871e40c7536720fce290c3467d33061
Summary:
Pretty trivial; new type of mount item & new method in the component protocol.
The default implementation in `UIView+ComponentViewProtocol` does nothing.
Reviewed By: fkgozali
Differential Revision: D8053355
fbshipit-source-id: a0418edf17ca75c4b94942b04acd93f3ea5d27e0
Summary: Note: not all scrollview props and features (especially event listeners and imperative calls) are supported yet.
Reviewed By: fkgozali
Differential Revision: D7961868
fbshipit-source-id: 5277674fe976e089fd963066f78e705ad846d78d
Valentin Shergin
Aaron Brager
Kevin Gozali