Summary: We call this method in a constructor before the actual object is beeing constructed, so it's incorrect; it should be class method.
Reviewed By: mdvacca
Differential Revision: D9931315
fbshipit-source-id: 304ba8e2354f3f408cfa2bf1729266525a08f951
Summary: All integration with Bridge was removed from RCTFabricSurface, now it's Surface's responsibility to start and stop JS app and register the ShadowTree in the Scheduler.
Reviewed By: mdvacca
Differential Revision: D9931317
fbshipit-source-id: 55a682f0afb1c542a904e1a8570029e4690967cc
Summary: Now we have a way to enumerate surfaces stored in RCTSurfaceRegistry.
Reviewed By: mdvacca
Differential Revision: D9931316
fbshipit-source-id: 6b886c4b52cebddf15fef0239190fb2730d682cc
Summary:
Several reasons:
* We are fulfilling a promise that RCTScheduler is just a very thin interop proxy between C++ and Objective-C;
* We have to pass all parameters down to Scheduler anyway, so instead of creating all of them separately and then passing one-by-one, we consolidate them into Context created where we have all those values.
In the future, we probably will move it to some dedicated place.
Reviewed By: mdvacca
Differential Revision: D9884892
fbshipit-source-id: f1d5744e4044bc4bdfe53ec9a97ee61dcf0c60c2
Summary:
To dispatch events synchonously on the main thread we still have to block the Message Queue.
We actually dispatch events on the Message Queue while the main thread is waiting.
Reviewed By: mdvacca
Differential Revision: D9799853
fbshipit-source-id: 8033be36f27371ad2f1dc7210d564fbca1174910
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
Summary:
When text nodes are nested, as below, `onPress` handlers need to be correctly invoked:
```
render() {
return (
<Text onPress={() => console.warn('hi')}>
hi
<Text onPress={() => console.warn('ramanpreet')}>ramanpreet</Text>
</Text>
);
}
```
In the above example, clicking on "hi" should warn "hi", and clicking on "ramanpreet" should warn "ramanpreet". This diff implements that behaviour.
Reviewed By: shergin
Differential Revision: D9696905
fbshipit-source-id: 2daf24e76c3b3c37aa36cd1540e54876a367faf7
Summary:
This diff includes two changes:
1. Even though `RCTViewComponentView` conforms to `RCTTouchableComponentViewProtocol`, it never implemented this protocol. This diff makes the correction.
2. Make the necessary changes to `RCTSurfaceTouchHandler` required by the changes in `RCTTouchableComponentViewProtocol`. This means modifying the `ActiveTouch` struct to hold `SharedTouchEventEmitter`s. It also means passing in the touch point to the `componentView`'s `touchEventEmitterAtPoint` method.
Reviewed By: shergin
Differential Revision: D9696909
fbshipit-source-id: 3d4a833f7dbae6d0238a0807eb2220250ccbae3d
Summary:
@public
Besides `pointerEvents` there are other two props that affect hit-testing mechanism: `zIndex` and `clipToBounds`.
The default UIKit implementation does not take this into an account (it always assume that `clipToBounds` is true and `zIndex` is same). `betterHitTest` does it right.
Reviewed By: sahrens
Differential Revision: D9688876
fbshipit-source-id: dadfd5e5541ddd1a744fbd8c6b10949c0e266069
Summary:
@public
In RN we have special `pointerEvents` prop that controls whether the View can be the target of touch events.
This is a pretty straight-forward implementation of that.
Reviewed By: sahrens
Differential Revision: D9688877
fbshipit-source-id: 1524647b0a33e4dd14563f531d636469bf3bdef7
Summary:
@public
Apparently, we have to call `ReactFabric.unmountComponentAtNode(tag)` instead of `AppRegistry.unmountApplicationComponentAtRootTag(tag)`.
Reviewed By: sahrens
Differential Revision: D9652730
fbshipit-source-id: f56dba7dbe5421a7d939b91178db5104476fe550
Summary:
@public
RCTSurfaceRegistry always promised this in the documentation but never actually did.
Reviewed By: sahrens
Differential Revision: D9652732
fbshipit-source-id: f3d06b95192e024273dc0e3a1c2753ca92370338
Summary:
@public
Apperently, we don't need to store and parse this because we are already doing this for `yogaStyle` field.
Reviewed By: sahrens
Differential Revision: D9649549
fbshipit-source-id: a84a5518674f4c2d574a060cdbebb9562121f5f4
Summary:
@public
Now all configurations or border styles are supported by RCTViewComponentView (and all subclasses).
Reviewed By: sahrens
Differential Revision: D9631868
fbshipit-source-id: 3a5b141ac5ffa9c28f4ebb0718f2fc935b8f1a75
Summary:
@public
Previously, ViewProps class coundn't represent whole spectre of possible values of border metrics (e.g. the border color was unified).
Now it's complete and direction-specific.
Reviewed By: sahrens
Differential Revision: D9628361
fbshipit-source-id: 6d3b3d4d7e3008e2168cbca732ff99fe5ea595e8
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
Summary:
This diff contains several tight to each other changes (which can/should not be split into several diffs):
* The props parsing/conversion process was de-virtualized: we don't use virtual `apply` method to parse props anymore. Instead, we use old-fashioned constructors.
* All fields of Props classes which represent props values were marked as `const` which make impossible to modify them after the objects were created (even if we have non-const value-of/pointer-to the whole Props object). Those fields are also `public` now.
* All custom handwritten getters were removed (because we don't need them anymore).
So, now we don't need all those custom getters which makes code much more compact, performant and codegen-friendly.
Reviewed By: fkgozali
Differential Revision: D7901245
fbshipit-source-id: 9f4b1fd2da64bf963b63215ed3bd74b9d3c58dd5
Summary:
This diff deprecates `-[RCTSurface rootViewTag]` in favour of `-[RCTSurface rootTag]` which returns
same value but represented as `ReactTag` (`long`) instead of `NSNumber *`.
Reviewed By: mdvacca
Differential Revision: D7857044
fbshipit-source-id: f5427c30d3de2d3563e830f2caac70b7dc9631f9
Summary: Quite trivial but still very cool recycling of native view instances is finnally here, in React Native. �
Reviewed By: mdvacca
Differential Revision: D7804085
fbshipit-source-id: 644804da3185f9ed3fdea42d4d76c93e86934448
Summary: We do not have a clear strategy how to deal with layout-only (view-less) components. Even if this particular solution is not so fancy, it prevents crashing during text rendering.
Reviewed By: mdvacca
Differential Revision: D7785885
fbshipit-source-id: f3ed8988aa2b41349fd1693c2a7f8c9368daee43
Summary: RCTParagraphComponentView is a UIView which can render text using TextLayoutManager.
Reviewed By: mdvacca
Differential Revision: D7751853
fbshipit-source-id: e6ee9a0f989cdf6e878390d37dbcf8a11ef90bf4
Summary:
This will be useful for this class and for subclasses soon.
For instance, when we draw something in `drawRect:`, we need to know exact content frame for rendering.
Reviewed By: mdvacca
Differential Revision: D7751855
fbshipit-source-id: 5d688368edd7b4f3c8c19d54ca701a9cc361270b
Summary:
Implementation of the native view component of <View>.
Root View also must have dedicated class even if its empty now.
Reviewed By: mdvacca
Differential Revision: D7526406
fbshipit-source-id: 9e14c9f679396c2cdb2d64c99086bb19df37c25c
Summary:
RCTSurfacePresenter coordinates presenting of React Native Surfaces and represents application-facing interface of running React Native core.
SurfacePresenter incapsulates a bridge object inside and discourages direct access to it.
Reviewed By: mdvacca
Differential Revision: D7526413
fbshipit-source-id: 9b6c513ec63a84d8b6c0951458cbd6b47f49669b
Summary:
RCTScheduler represent facebook::react::Scheduler as a Obejctive-C object.
It supposed to be single, unified, bidirectional interop layer between C++ and Obejctive-C worlds.
Reviewed By: mdvacca
Differential Revision: D7526405
fbshipit-source-id: a206755f64f2904981b356a40e7659922b24d7bb
Summary: RCTFabricSurface was reimplemented as separate class which does not rely on (old) RCTUIManager and delegate some functionality (which must be coordinated between Surface instances and Scheduler) to RCTSurfacePresenter.
Reviewed By: mdvacca
Differential Revision: D7526404
fbshipit-source-id: e8c38261bc489fd6066ba29a829cd8f623c26217
Summary:
A registry for components. The registry allows to refer to component view instance by react tag.
It also has recycle-pool-like interface (and eventually the pool will be implemented).
Reviewed By: mdvacca
Differential Revision: D7507519
fbshipit-source-id: ed74203fb4d0694490b0dc23aae0aa067b3fc55b
Summary:
MountItem is a small granular light-weight instruction describing a change in the component view tree.
All instruction are supposed to be small and standard. All additional logic must be implemented in component view subclasses.
No more opaque and untyped objcblocks.
All that allows mounting manager to control and optimize an execution of those items (eventually).
Besides that five we probably will need `perform imperative instruction` (for execution something like `scrollTo`) and `update local data` (for updating local state of something like text input).
Reviewed By: mdvacca
Differential Revision: D7507518
fbshipit-source-id: 745b93125231a02cbc152cfa6c6baf423d100f81
Summary:
All methods of RCTComponentViewProtocol are non-optional,
but this default implementation removes necessity to implement all of them manually.
Reviewed By: mdvacca
Differential Revision: D7507522
fbshipit-source-id: e4dff97e8bf64e79d2f1ffca94f0549bd4b5e2fa
Summary: RCTComponentViewProtocol is a protocol for all UIView instances which are managed by React/MountingManager.
Reviewed By: mdvacca
Differential Revision: D7507520
fbshipit-source-id: dcbed8c5d0cc97f72942508aeccb445833ade271
Summary: UIManager uses UIManagerDelegate to communicate about shadow tree changes to another parts of the system.
Reviewed By: fkgozali
Differential Revision: D7503484
fbshipit-source-id: 0afe0f0d6cad31fe2ee9d61235d02b379cfe8217
Summary: The RCTRootView default needs to be translated during init of RCTSurfaceHostingView correctly.
Reviewed By: shergin
Differential Revision: D7327918
fbshipit-source-id: 67a2a42b554782b37a032cc0470d794554cc1e5a
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Valentin Shergin
Héctor Ramos
Ramanpreet Nara
Aaron Brager
Kevin Gozali
Naris Siamwalla
Sophie Alpert