Summary:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary: The code fragment `super.accessibilityLabel` always meant "use stored value which came from Props". But after we override the implementation of this getter in the base class, this starts working differently (wrong). This change basically reverts that to original intent.
Reviewed By: sahrens
Differential Revision: D10350597
fbshipit-source-id: 913951eb08c4ede76fc0e9be76b48d86599bcc62
Summary: Empty string in AccessibilityProps basically means same as `nil` in iOS Accessibility API.
Reviewed By: sahrens
Differential Revision: D10350596
fbshipit-source-id: fad9cdc914388c72e1b8261b27f14cbfa9a037db
Summary: We didn't have support for them... and now we have it.
Reviewed By: sahrens
Differential Revision: D10280430
fbshipit-source-id: 7275d4617ed3994366f673a17c24b823293d7092
Summary:
This diff fixes previously broken custom border rendering.
We need a dedicated CALayer for border bitmap in order to fully support all UIView capabilities in case if some subclass uses that. Otherwise, any call of `drawRect:` method can override any content which is stored inside `contents` property of CALayer.
Q&A:
How does it work in current RN? - It does not. All `drawRect:` methods in RCTView subclasses are dysfunctional.
How does text view work in current RN? - RCTTextView does not inherit RCTView, so it does not have this problem.
How does text view support custom borders in current RN then? - It does not.
Reviewed By: PeteTheHeat
Differential Revision: D10228805
fbshipit-source-id: 22bc31f41ab1914a97f3a5981cd1b24ebca725cd
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
Reviewed By: sahrens
Differential Revision: D10081501
fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
Summary:
Don't ask.
Really, all those descriptions from official docs like below are useless:
* `__bridge_transfer` Moves a Core Foundation pointer to Objective-C with transfer of the ownership to ARC.
* `__bridge` Transfers a pointer between Objective-C and Core Foundation with no transfer of ownership
All that is totally confusing and useless. At the end of the day, we only have to think about which additional `CFRetain` and `CFRelease` ARC will add or will not add for our pointers.
So, following official docs recommendation, we would like to add `__bridge_transfer` because of course, we do want to ARC managing the variable after we introduced it to ARC here. But we also want to have shared ownership of this. That's the key. If we use `__bridge_transfer` ARC will assume that this variable already retained once (because it exists) and will call CFRelease at the end of the scope. Right before that when we pass this variable down to call stack ARC will retain and then manage the variable according to the rest of the code. But still, from this point, we will have zero-balanced reference counter; the owning by `shared_ptr` bump is already compensated with `CFRelease` at the end of the scope. As soon as the rest of the code release the object, it will be incorrectly deallocated.
So, instead of using `__bridge_transfer` we have to use `__bridge`. That will indicate that *in this block* ARC does not manage the reference counter of the variable (which is kinda true because having `shared_ptr` inside the block already retains that) and will not add `CFRelease` at the end of the block.
Reviewed By: mdvacca
Differential Revision: D10054241
fbshipit-source-id: 6e82c5270fe5d53f1ed68e167b94f70dc4367a9f
Summary: Apparently, after updating CALayer props we have to request redrowing on top of it manually.
Reviewed By: mdvacca
Differential Revision: D10053340
fbshipit-source-id: f87311399bab809c9e13a3076f526bbe3f7f3fb4
Summary:
Instead of wrapping all public methods into The controller you requested could not be found. blocks/mutexes, RCTSurfacePresenter utilizes a different thread-safety pattern where all instance variable are granularly thread-safe.
The names of all internal methods were prefixed by '_'.
Reviewed By: mdvacca
Differential Revision: D10033407
fbshipit-source-id: 97fd2879c879dd9ef8d9ece24e25af00f749a871
Summary:
There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
Reviewed By: mdvacca
Differential Revision: D9999336
fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
Summary: Besides that it's more simple and straight-forward now, we need that to always instantiate Scheduler with a context full of fresh valid objects derived from the new instance of the bridge.
Reviewed By: mdvacca
Differential Revision: D9995780
fbshipit-source-id: 534a314152d93562b08dd7857962f174b0d06886
Summary:
The original design of RCTSurface implied that the Surface starts on initialization and stops on deallocation. Recently I realized that this not sufficient API in some cases when the application uses ARC with autorelease pools (that can postpone object deallocations, which is highly undesirable).
And that's simply handy to have those methods sometimes.
Reviewed By: mdvacca
Differential Revision: D9982356
fbshipit-source-id: baa3bd24804d3708606ebd00b8795f2d5c9d4de9
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
