Summary:
@public
Removes all `YG...Count` macros for enums and replaces them with `facebook::yoga::enums::count<YG...>()`.
This removes the need to manually maintain enum counts.
Same as D13597449, working around a defect in clang < 3.9
Reviewed By: amir-shalem
Differential Revision: D13634622
fbshipit-source-id: 344dc70e167b0caf746fe396cedd200f54e52219
Summary:
@public
Removes all `YG...Count` macros for enums and replaces them with `facebook::yoga::enums::count<YG...>()`.
This removes the need to manually maintain enum counts.
Reviewed By: shergin
Differential Revision: D13597449
fbshipit-source-id: edcee225ada4058e94f3a727246763e3cc45873d
Summary: This diff ensures that the 'measure' method in TextLayoutManager is memoized using a static variable.
Reviewed By: fkgozali
Differential Revision: D13585508
fbshipit-source-id: 9275a4d193b8abb0c3aaffd5a5535234717475e1
Summary:
This diff fixes a race condition that was detected on "Marketplace You" production test for Android.
The race condition happens when the method ShadowTree::complete is executed concurrently from two threads (in this case this is called from Scheduller::constraintSurfaceLayout and Scheduler::uiManagerDidFinishTransaction), based on the order of execution this bug makes MountViewItems to be dispatched to the UI in the wrong order.
The root cause of the bug is in the method:
```
bool ShadowTree::complete(
const SharedRootShadowNode &oldRootShadowNode,
const UnsharedRootShadowNode &newRootShadowNode) const {
newRootShadowNode->layout();
newRootShadowNode->sealRecursive();
auto mutations =
calculateShadowViewMutations(*oldRootShadowNode, *newRootShadowNode);
if (!commit(oldRootShadowNode, newRootShadowNode, mutations)) {
return false;
}
emitLayoutEvents(mutations);
if (delegate_) {
delegate_->shadowTreeDidCommit(*this, mutations);
}
return true;
}
```
Notes:
- the commit method is guarded by the commitMutex_
- the shadowTreeDidCommit() method dispatches mutations instructions to the platform side.
- If there are two threads running concurrently, there is no guarantee that the shadowTreeDidCommit() is going to be called in the correct order.
The solution is to include the execution to shadowTreeDidCommit() in the same commitMutex_
Possible solutions:
1 - move the commitMutex_ out of the commit method (to the completeMethod)
2 - synchronize the call to complete method() - this is the implemented solution.
I chose this solution to make it consistent with the way Scheduler::constraintSurfaceLayout is implemented (https://fburl.com/8l49no5x)
This mechanism is very likely to change in the refactor of threading mechanism that Valentin Shergin is going to be working on January.
I would like to land this, so we can fix this bug and run another experiment in production as soon as possible.
Reviewed By: sahrens
Differential Revision: D13535587
fbshipit-source-id: bedd4d85f5569ab3733c302d1328aa48017bcaad
Summary:
shergin mentioned that he'd like to move away from RTTI a bit and use explicit key strings for context container instances rather than relying on the `typeid`, so this does this.
We also fatal with a useful error message if we get a collision, rather than failing silently.
Reviewed By: shergin
Differential Revision: D13384308
fbshipit-source-id: 0b06d7555b082be89e8f130c23e94be99749a7a3
Summary: We need a way for different apps to inject dependencies or additional functionality into Fabric - ReactNativeConfig might be a special case, but I think this could clean up it's integration nicely, and I'm using this for a uitemplate cache system so we can use CompactDisk or other storage systems for caching depending on the app.
Reviewed By: mdvacca
Differential Revision: D13407287
fbshipit-source-id: 45481908434e6235850aa4d2d6b2bfb936a23be7
Summary:
@public
The storage format of `YGValue` in `YGStyle` is an implementation detail that is going to change soon. It is only guaranteed to be assignable from, and castable to `YGValue`.
Here, we remove tight coupling from the actual implementation in React Native.
Reviewed By: shergin
Differential Revision: D13465113
fbshipit-source-id: 41dfcb90c2a1cd825a6732854bf84d4c3318d835
Summary:
@public
When switching to `CompactValue`, casting edges or dimensions to `std::array<YGValue, ...>` will do actual work.
In order to avoid that from happening implicitely, we remove the casting operator.
Reviewed By: SidharthGuglani
Differential Revision: D13464292
fbshipit-source-id: 217065b001a63cfa8adde715063682c583007a4d
Summary:
This diff fixes a style property that was incorrectly mapped as `textDecorationLineType` in Fabric
This was correctly mapped in classic here: diffusion/FBS/browse/master/xplat/js/react-native-github/Libraries/Text/BaseText/RCTBaseTextViewManager.m;10b92f1847cdec8a3f0a996f218989766516f805$48
Reviewed By: mdvacca
Differential Revision: D13443921
fbshipit-source-id: 7fafaf2492d8c3b938f2e433a983303958e5c578
Summary:
@public
Replace `YGFloatOptional::getValue()` with `YGFloatOptional::unwrap()`.
`YGFloatOptional::getValue()` has the unfortunate property of calling `std::exit` if the wrapped value is undefined.
Here, we eliminate the method, and just call `.unwrap()` everywhere.
Reviewed By: shergin
Differential Revision: D13439608
fbshipit-source-id: 5ae82b170537d0a10c301412567a7a66fd50bab4
Summary:
@public
`YGFloatOptional::getValue()` has the unfortunate property of calling `std::exit` if the wrapped value is undefined.
That forces `x.isUndefined() ? fallback : x.getValue()` as access pattern.
Here, we replace that by introducing `YGFloatOptional::orElse(float)` which encapsulates that pattern. Other additions are `orElseGet([] { … })` and some extra operators.
Reviewed By: SidharthGuglani
Differential Revision: D13209152
fbshipit-source-id: 4e5deceaaaaf8eaed44846a8c152cc8b235e815c
Summary:
In some setup, buck cxx test for android runs with `NDEBUG` set, hence we can't call debug symbols in the test cases. So guard those callsites with `#ifndef NDEBUG`.
Also, some dependencies for this test target depend on Android specific symbols, so we have to mark it as instrumentation test for now (FB-specific).
Reviewed By: sahrens
Differential Revision: D13337637
fbshipit-source-id: 02ff152df9937f2b0b8596f53789cdee8ee8a539
Summary: For configuration purpose, pass down config object from the hosting app and use it in UITemplateProcessor.
Reviewed By: sahrens
Differential Revision: D13290322
fbshipit-source-id: 8bb6d7f5a3f977b873e548e15603259876b46dc8
Summary:
`ShadowTree` class is already thread-safe, so we don't need to (we should not) guard concurent access to it.
We should guard concurrent write-access to the collection of them though.
Note that unordered_map is "thread-compatible" collection, so concurrent reading access is okay.
Reviewed By: mdvacca
Differential Revision: D13269745
fbshipit-source-id: 4779626018da0e42b81a835e538f6c1d1a8e25f7
Summary: Trivial diff that cleans up measure function in C++ and Android
Reviewed By: shergin
Differential Revision: D13200340
fbshipit-source-id: 6c0888439640241cdedf514898a1ba3dac231d6a
Summary: Pretty straight-forward migration to using `JSI` instead of `folly::dynamic` in `TouchEventEmitter`.
Reviewed By: sahrens
Differential Revision: D13123042
fbshipit-source-id: 594b89b6e3986d6a04846194701e3a727b152cec
Summary: Pretty straight-forward migration to using `JSI` instead of `folly::dynamic` in `ScrollViewEventEmitter`.
Reviewed By: sahrens
Differential Revision: D13123049
fbshipit-source-id: 2839976d0119c48fa2538dbaa53afbc24982c598
Summary: Pretty straight-forward migration to using `JSI` instead of `folly::dynamic` in ViewEventEmitter.
Reviewed By: sahrens
Differential Revision: D13123048
fbshipit-source-id: 3c323912d3e65b684f99df6cda99c785876164af
Summary: Pretty straight-forward migration to using `JSI` instead of `folly::dynamic` in SwitchEventEmitter.
Reviewed By: sahrens
Differential Revision: D13123046
fbshipit-source-id: f2e4905a96191540ceec633bae1871c93be724db
Summary:
Now the event delive pipeline supports `JSI::Value`-based payload. Instead of passing `folly::dynamic`, now we are passing `std::function<jsi::Value(jsi::Runtime &runtime)>` as factory that can build a `JSI::Value` with given `jsi::Runtime` and any captured data.
The old (now legacy) way of calling `EventEmitter::dispatchEvent(..., const folly::dynamic &payload, ...)` is also supported.
Reviewed By: sahrens
Differential Revision: D13123043
fbshipit-source-id: d65348bb215013042abb2fcfe5083a8c697333d0
Summary: Now instead of passing `reactTag` through the whole event pipeline, we store it inside `EventTargetWrapper` (and it does not leave `UIManagerBinding`). It helps with reducing the complexity of `EventEmitter` and will help us in migrating to JSI.
Reviewed By: sahrens
Differential Revision: D13123045
fbshipit-source-id: aa9ee94d5660ff3090369c1e55cf748d2e72b987
Summary:
That's generally better because:
* Avoids exposing ShadowNode to mounting layer;
* Enables hashing and comparing the AttributedString based on actual meaningful data (not on just a pointer to ShadowNode).
Reviewed By: mdvacca
Differential Revision: D13205230
fbshipit-source-id: 7b79c1aad97b10d81e3faa10408be61b74f815cf
Summary: Trivial. We need this for future use as part of AttributedString's hash.
Reviewed By: mdvacca
Differential Revision: D13205231
fbshipit-source-id: 14a3decae72741030284a30abdb936616bafb3fe
Summary:
ShadowView, ShadowViewMutation, and Differentiator were decoupled to separate module.
That enables us to use ShadowView more widely without facing a circular dependency problem.
Reviewed By: mdvacca
Differential Revision: D13205229
fbshipit-source-id: 7373864bf153a7813c2f97edb263a41454ce0b88
Summary: Pretty straightforward wiring UIManager and the new feature in ShadowTree: we get the node, clone with the new props and then replace this.
Reviewed By: sahrens
Differential Revision: D13114788
fbshipit-source-id: 3a34fb879f3ec564c26278034a19b88518302de8
Summary: This method is the core of the future features: `setNativeProps` and `LocalState`.
Reviewed By: sahrens
Differential Revision: D13114789
fbshipit-source-id: 2138496c43c171fe27784b1959d86d6eec4638ee
Summary:
Previously, we stored a pointer to ShadowNode inside NSAttributedString's attributes to make possible retrieving an EventEmitter associated with some text fragment.
That worked fine besides only one caveat: the internal implementation of NSAttributedString is quite strange and that causes a memory leak. Because of some reason, NSAttributedString does not release stored attributes after own destruction (maybe OS uses some kind of caching).
So, now, instead of storing a strong pointer to ShadowNode inside NSAttributedString, we store a weak pointer to EventEmitter. Storing a weak pointer is okay because a desired lifetime of EventEmitter is guaranteed by LocalData stored inside a View. Storing a weak EventEmitter instead of weak ShadowNode will also help us with migration to ShadowView (we cannot store ShadowView weakly because it's a stack allocated object).
Reviewed By: sahrens
Differential Revision: D13196886
fbshipit-source-id: f8714e4b3709765629d6456edf0c635bf5f7c53b
Summary:
Consider this:
* ParagraphShadowNode retains LocalData,
* LocalData contains AttributedString,
* AttributedString contains Fragments,
* Fragment can contain a pointer to parent shadow node, so it can be the ParagraphShadowNode.
In this case it's a retain cycle.
We actually don't need to store pointers to not TextShadowNodes, so we don't now.
Later, after we fully migrate to ShadowView, we can remove this condition because it will become harmless.
Reviewed By: sahrens
Differential Revision: D13196885
fbshipit-source-id: d386ce0a067df0a72e6619d62d56038aaf80eccb
Summary:
Apparently, the previous behavior brings more problems than some *possible-in-the-future* features and flexibility.
The new model allows us to easily implement "nested text" feature.
(We temporary hope the old behavious for Android only for compatibility reasons.)
Reviewed By: mdvacca
Differential Revision: D13176277
fbshipit-source-id: 01f7bfb3c2e70cc89d76ecb78add016ee91cbd63
Summary:
This diff changes the method to calculate the hash of an AttributedString (removing shadowNode and parentShadowNode from it).
This is necessary becuase otherwise hashcode of clonned parent keep changing in every state change, when the text doesnt change
With this change we are able to cache spannables in android properly
Reviewed By: shergin
Differential Revision: D13189110
fbshipit-source-id: c1f7372809ce98a5b4d091485cc15281a4ab5e1e
Summary:
Removing two props that are not currently used
They are being set as quiet_NaN in C++ and this brings problems in the Android side
Reviewed By: shergin
Differential Revision: D13188600
fbshipit-source-id: e8412497a80300cfbc3770b829e9633206aaf427
Summary: In this diff we expose the text local data hash to android, this will be used in the future to cache metadata when rendering text in android
Reviewed By: shergin
Differential Revision: D13161873
fbshipit-source-id: cd13a4beba75a3fe62ac9ff3def26f88e874834b
Summary: Simple diff that adds a systrace to start measuring the calculation of Yoga layout() in Fabric
Reviewed By: shergin
Differential Revision: D13124641
fbshipit-source-id: 6bd03e9f56524221f5d91606ffde50253673c1bb
Summary: This diff refactors the types used when Yoga requires to measure the size of a View in C++
Reviewed By: shergin
Differential Revision: D13124086
fbshipit-source-id: 89dfe80bb41b4fb2eaba84af630d52ef2509b1e1
Summary: Now we don't update `LocalData` for `ParagraphShadowNode` if the attributed string hasn't changed.
Reviewed By: mdvacca
Differential Revision: D13160128
fbshipit-source-id: 6ffe76ad187452fa37ba36a132b885cbcedfd1d3
Summary: This method is underlying infra for all `measure`-like methods exposed to JavaScript.
Reviewed By: mdvacca
Differential Revision: D13036553
fbshipit-source-id: cb5135f1db97ec8144b31a24ee4fb9f5d61f0df1
Summary: The diff adds a pointer to ShadowTreeRegistry to UIManager which enables the possibility of implementing ShadowTree mutating and inspecting methods like `setNativeProps` and `getRelativeLayoutMetrics`.
Reviewed By: mdvacca
Differential Revision: D13036549
fbshipit-source-id: 5ed1252d84c8dd895fe0e6e8cc71afbaa9dab4b7
Summary:
Why do we need a dedicated registry class?
* We need to simplify registry-related logic in Scheduler.
* We need to couple threading aspect of the registry with the registry itself, otherwise it's not clear why exactly we acquire the mutex. We also should not acquire the mutex in a per-method way (as we did before), because it's incorrect and misleading (only lines that access the registry should by protected).
* We need to have a way to share the registry with other classes (e.g. UIManager) without passing a reference to the whole Scheduler.
Reviewed By: mdvacca
Differential Revision: D13036550
fbshipit-source-id: 644da910e823666c586834a3da2b4cdcb90eebb2
Summary: Trivial. Those are not used.
Reviewed By: fkgozali
Differential Revision: D13017883
fbshipit-source-id: cf285e537eb85c8fca6852f7c03a5ef661b85757
Summary:
The generic method that returns relative (to some specified node) layout metrics.
We need this as a building block to implement `UIManager.measure*()` methods family.
Reviewed By: mdvacca
Differential Revision: D12932549
fbshipit-source-id: 79064551d32b0cd40e72dc87d0ed194e3779ba29
Summary:
We have to have a way to backtrack a pointer to a parent node and this is generalized version of that.
This is the first naive implementations of the algorithm. We will invest in optimizing this later.
Reviewed By: mdvacca
Differential Revision: D12920856
fbshipit-source-id: 9facb4e16a0b5608feb6747df3804952025ef093
Summary: This diff adds support for layout constraint when measuring text
Reviewed By: shergin
Differential Revision: D13111434
fbshipit-source-id: 0c8689e9ac8ce2281b03386f275d2a8e034f88d8
Summary: trivial change of the default font size from 12 to 14 to make it backward compatible with current version of RN
Reviewed By: shergin
Differential Revision: D13108543
fbshipit-source-id: e5e384c4459f2c87ee9589c4e00a0ab5d0c8a06a
Summary: This diff fixes the dispaching of Async Events in Android C++ layer to ensure proper asynchronouns dispatching in the JS thread.
Reviewed By: shergin
Differential Revision: D12988348
fbshipit-source-id: 7aa60b11e2c264c2e68354ed83eb75139060d211
Summary:
This pull request fixes a path name to be a proper case in `UITemplateProcessor`, which fixes this build warning:
```
{snip}/react/uimanager/UITemplateProcessor.cpp:17:10: warning: non-portable path to file '<react/core/ComponentDescriptor.h>';
specified path differs in case from file name on disk [-Wnonportable-include-path]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<react/core/ComponentDescriptor.h>
1 warning generated.
```
Pull Request resolved: https://github.com/facebook/react-native/pull/22239
Differential Revision: D13020871
Pulled By: shergin
fbshipit-source-id: 77555018cd569880518ff884ed8768effc4ea97e
Summary: This diff changes the behavior of the Scheduler.schedulerDidRequestPreliminaryViewAllocation to avoid pre-allocating views that are non-layoutables
Reviewed By: shergin
Differential Revision: D12962008
fbshipit-source-id: cb2670beafdcbd2116fbdaf2dc5d1b4726330ec2
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: In the previous approach, when event emitter got disabled for split second, we could lose the EventTarget because JS GC can collect it before we re-enable this. Now we "over-enable" this first, and "under-disable" later.
Reviewed By: mdvacca
Differential Revision: D12990112
fbshipit-source-id: 4e3c0c0e05f03509ec72ca570f59ce16597353f0
Summary: ShimmeringView is called: RTShimmeringView Android and ShimmeringView in iOS. This diff adds a mapping into ComponentDescriptorRegistry to temporary enable ShimmeringView component until we can unify names in JS.
Reviewed By: sahrens
Differential Revision: D12991351
fbshipit-source-id: 48e08b8021116221ccfd5f2512c76f65145baa2a
Summary: This diff exposes rootTag as part of SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation(). This will be necessary to be able to pool views per Surface in Android
Reviewed By: shergin
Differential Revision: D12875656
fbshipit-source-id: d2a8c1f9bcc6b14c17b34bf59085da44ae3c3416
Summary: This diff adds systrace support in the C++ side of Fabric
Reviewed By: ejanzer
Differential Revision: D12861373
fbshipit-source-id: 0291f3e406f239bbef3686ac0bba6e9f1c7eac57
Summary: AndroidSwipeRefreshLayout is rendered in the "Marketplace Your Items" screen altough it is disabled. This diff just temporary implements the AndroidSwipeRefreshLayout component as a View (similar to the iOS counterpart RefreshControl).
Reviewed By: shergin
Differential Revision: D10524049
fbshipit-source-id: 5df38fbdf1339b3857138d82a7100ec7f15854b3
Summary:
This patch fixes the the assignment of Y coordinate information in the event payloads in `TouchEventEmitter`, which were inadvertently being assigned X coordinate data.
Pull Request resolved: https://github.com/facebook/react-native/pull/22160
Differential Revision: D12943125
Pulled By: shergin
fbshipit-source-id: a3fde64c4d6c76784f1a0ac7cae4c0d62f3d4497
Summary:
This diff changes how we expose UIManager to JavaScript realm and control ownership of it. This change should improve reliability and a thread-safety.
UIManagerBinding is a HostObject which consolidate ownership of UIManager. Now JavaScript's GC controls its lifetime which eliminates the possibility of calling some JS facing methods of UIManager using a dangling pointer.
Besides that, all API now imply that if the caller has a reference to jsi::Runtime, it calls the method on the proper thread (it's an implication of RuntimeExecutor design).
Reviewed By: sahrens
Differential Revision: D12876745
fbshipit-source-id: eb8c70317460df5b14e45031ad15fc6c8e5b5ce3
Summary: We need to decouple this from actual JSI/UIManagerBinding implementation to make them more maintainable.
Reviewed By: sahrens
Differential Revision: D12876742
fbshipit-source-id: 30cad69d0a9761e2aa82f31d180e4b5a40cedb61
Summary: This is more usable (because it allows to use `->` operator) and safe (const-style) methods replacing old `operator[]` methods.
Reviewed By: mdvacca
Differential Revision: D12876744
fbshipit-source-id: 8ea7398c9777f8be3e88db873ec00915d0761615
Summary:
We double down on JSI in Fabric. So, practically, JSI is now a hard dependency for Fabric. I hope it's for good.
Now `jsi::Runtime` is coupled with scheduling via `EventExecuter`, so we have to make `jsi::Runtime` a part of `EventBeat` to proxy runtime reference to bindgings.
Reviewed By: sahrens
Differential Revision: D12837225
fbshipit-source-id: 98edc33d6a3358e6c2905f2f03ce0004a9ca0503
Summary: Apparently, the standard does not guarantee that the vector is empty after moving from it. So, let's clear it explicitly instead of asserting the emptiness.
Reviewed By: sahrens
Differential Revision: D12837227
fbshipit-source-id: 85dff6848707f4204f4c79be173064547e83c63e
Summary: React bytecode is kind of a different thing that sebmarkbage already has in mind so lets keep the namespace separate.
Reviewed By: mdvacca
Differential Revision: D12896293
fbshipit-source-id: e0f266da6e7a051bcf5defea49b958452342754d
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
* Adds parent tag as param for createNode in place of explicit appendChild commands.
* Adds version info to bytecode
* Adds native conditional support:
Conditionals are represented in product code with the new `NativeConditional` React
component. It takes params necessary to construct a native function call, and takes
a render prop as a child that passes the value of the native call as an arg. In
prod, the component would actually call the native module and render with that value,
but in jest we render for *both* true and false and set them as children
of a new jest-only primitive/host component which we special-case and generate a
special command with `OP_CODE.conditional`, generate the appropriate bytecode commands
for each branch, and embed them as args in the conditional OP_CODE command. When
evaluating the bytecode, only one set of commands is executed, based on the native
module value (which is evaluated with another new opcode which computes the value
and stuffs it in a "register").
Obviously generating this bytecode is kind of a cludge compared to prepack, but
when I asked @[501709947:Dominic] about it, he said they had no bytecode spec right
now, so I'm running ahead with this prototype. The main thing I'm focused on is
the C++/RN bytecode interpretter - this jest stuff is just a way to generate bytecode
for it to consume which could be replaced or augmented with many other approaches,
such as prepack, server rendering, etc.
Also piggybacked a bunch of other cleanup.
Reviewed By: shergin
Differential Revision: D10277121
fbshipit-source-id: 15d3217a59ef481b574c742d17d8a7dc893cba90
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
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: ImageManager is used to update the LocalData of Image views, as part of this process we call ImageManager::requestImage in cross platform code. Event if Android doesn't use ImageRequest we need to return an empty non-operation version of this object.
Reviewed By: shergin
Differential Revision: D10429663
fbshipit-source-id: 3621ece72f7291e2e6ab6a84b238ac16b595fc18
Summary:
The first implementation of EventEmitter's enable/disable feature didn't not provide a way to enable an object after it was disabled.
Apparently, we need this functionality due that fact that all nodes of the same family share same event emitter.
Reviewed By: mdvacca
Differential Revision: D10395849
fbshipit-source-id: 0eba54f0bb7ded35d64afb6559e6e27208c2b577
Summary:
Trivial.
We have to proxy layout directions as well as min and max sizes to RootNode's Props to properly communicate the constrains to Yoga.
Reviewed By: sahrens
Differential Revision: D10387798
fbshipit-source-id: a02ec0a20b3ef28f6230738e5b3a4a2b0b8e0961
Summary: An `AttributedString` object generated by a cross-platform layer of React Native must have already resolved text styles to make the actual resulting text identical across platforms. To do so we have to have a unified default.
Reviewed By: sahrens
Differential Revision: D10287725
fbshipit-source-id: e8c62b33496be34146182baccd0009d3624a7fe5
Summary: This might be useful to specify some default props.
Reviewed By: sahrens
Differential Revision: D10284657
fbshipit-source-id: b6fbdc6bab75697af67bdbb5d06eb3309500ab8c
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 the release of ImageRequest object. The responseFutureSplitter_ can be destroyed by the time ~ImageRequest is executed. See P60163877 for original crash (this crash was reproducible when reloading or closing a Fabric screen that contains several images.
Reviewed By: shergin
Differential Revision: D10282207
fbshipit-source-id: 4f0894959e54f6d15b98e216df102e764866e387
Summary: missing header and platform. attributedstring builds now, but still fails because of T34990592
Reviewed By: mdvacca
Differential Revision: D10349210
fbshipit-source-id: dcd163df9ac9a4fcb36399cb9f93dbf1b33c062d
Summary: Simplies UIManager a bit and some other tweaks
Reviewed By: shergin
Differential Revision: D10211883
fbshipit-source-id: 93ab23dd2baab2fdc6d9c54e976b001a19efab7f
Summary: This diff avoids the serialization of color that are set as: "UndefinedColor". This allows the text rendering system to set the default color in the native side
Reviewed By: shergin
Differential Revision: D10275834
fbshipit-source-id: b81c7a5995bef65e04a246d99f44ff10cb20f548
Summary: This diff enables the onPress event for TextViews that render RawText
Reviewed By: shergin
Differential Revision: D10222183
fbshipit-source-id: 4b6a6ad548286453f7dd3a14a5e4ee453a55b923
Summary: This diff enables view flattening for Android when using Fabric.
Reviewed By: shergin
Differential Revision: D10254678
fbshipit-source-id: cc7acaa38a6d01e112ba0e8a92db61cdeefbffee
Summary: This diff introduces the collapsable props in the viewProps. This prop is used in product code to prevent specific Views to be removed from the view hierarchy
Reviewed By: shergin
Differential Revision: D10254679
fbshipit-source-id: 637665b8998a86e29e839eb6d405a0fac354c8d3
Summary: Previsouly, we basically didn't support Accessibility at all.
Reviewed By: mdvacca
Differential Revision: D10250635
fbshipit-source-id: d33eed8f56374f57310654653f41c312cb5942e6
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: Quite obviously, having a `complete` method which accepts only `newRootShadowNode` was a baaad idea. When we `complete` or `commit` we always have to have two nodes (before and after). And only after layout and right before swapping (and acquiring the mutex) we have to verify that *current* root node is still the same as it was when we initialized the transaction (if not, we have to abort).
Reviewed By: mdvacca
Differential Revision: D10201902
fbshipit-source-id: 15adc78c5d31d6fd39fd7fc6e53203a5539717a8
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: With new `ShadowTree::getRootShadowNode()` method all access to rootShadowNode_ is protected by commit mutex.
Reviewed By: mdvacca
Differential Revision: D10159456
fbshipit-source-id: 0bc8676ca2564a8ef95d60e912356e99d9f172c1
Summary:
Calling `uninstall` synchnously was a bad idea. Unfortunatelly, even if it illuminate possible race condition during uninstallation, sometimes it deadlock.
It's not clear for now how to solve both problems without introducting another layer of indirection between UIManager and JSI.
Reviewed By: mdvacca
Differential Revision: D10081500
fbshipit-source-id: 90d8120603929a8219a3e606d8b3527e297b13ce
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: In some cases we have to have a way to notify a EventBeat consumer that the beat cannot be (and will not be) delivered, so we introducing special API for that.
Reviewed By: mdvacca
Differential Revision: D10081503
fbshipit-source-id: 4c5a392d32572f426e3744bdba797efcd29b8cb4
Summary:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Summary: This diff unifies the 'handling' of the top prefix in the EventEmitter.cpp class
Reviewed By: shergin
Differential Revision: D10149497
fbshipit-source-id: d0ddbbbeefe3790b414b101da47582161354c971
Summary: This diff renames com.facebook.fbreact.fabric.UIManager to FabricUIManager, this is done in order to avoid confusion with com.facebook.react.bridge.UIManager
Reviewed By: shergin
Differential Revision: D10128635
fbshipit-source-id: 0cb874ec1ba698077d750214f1d25004065c2f59
Summary: This diff exposes the method EventEmitter.dispatchEvent as public in order to be able to access it from the android side.
Reviewed By: shergin
Differential Revision: D10127509
fbshipit-source-id: d6ddf59c654a91fdeed5fba867ca31d6de96d607
Summary: This change implements `onLayoutOnly` for regular bare <View> component (*not* for its descendants!) After this view flattening is actually starting working for all platforms.
Reviewed By: mdvacca
Differential Revision: D9511001
fbshipit-source-id: 3562dd1b7570a064150f100cc2e1bc4220b81290
Summary:
... instead of using direction access to `ygNode.getLayout()` object.
Suddenly, YGLayout object that YGNode exposes contains unresolved/directional-unaware styles. To get resolved directional-aware styles we have to use functions from Yoga.h.
I am not happy with this solution, I will try to implement something like `ygNode.getResolvedLayout()` and use that instead.
This change fixes strange missing horizontal padding around some views.
Reviewed By: mdvacca
Differential Revision: D10112049
fbshipit-source-id: 4b6ef39d8dd34e78a4592962e8af4eeaa5028768
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary: We have to uninstall UIManager synchronously to avoid a race condition when JS is capable to call already deallocated UIManager.
Reviewed By: mdvacca
Differential Revision: D10033406
fbshipit-source-id: 194d1ae2dd5ab09b036b1c165de289ada8e66014
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: This is the last step before making JSIUIManagerInstaller a direct dependency of UIManager (and making UIManager installation process completely seamless/platform-agnostic).
Reviewed By: mdvacca
Differential Revision: D9995781
fbshipit-source-id: 6f8c7177495b01ebaac1dbe330f49dce2e2a552c
Summary:
EventBeatBasedExecutor is an executor derived from EventBeat and using EventBeat to ensure proper threading.
Why do we need yet another executor? Because otherwise, we have to make it platform specific-dependency that each platform-specific implementation has to implement and provide. We already have all that we need in already provided EventBeat, so we can just convert that into simple executor in a platform-agnostic way.
Reviewed By: mdvacca
Differential Revision: D9995783
fbshipit-source-id: f8aa72a9744e50ebecbea9ad0e2546f41f5358f2
Summary: UIManager now can install and uninstall itself calling a functions that are provided as constructor arguments.
Reviewed By: mdvacca
Differential Revision: D9931329
fbshipit-source-id: b8d2d9925b0e2db0fed44bdf2e185d198fabd5ee
Summary: As it mentioned in the comment, we have to commit an empty tree as part of cleaning up Surface.
Reviewed By: mdvacca
Differential Revision: D9931320
fbshipit-source-id: 04e780bafdb917adeb89f2edef2dc0348b2a4d4a
Summary: This diff adds support for the ActivityIndicator component into the Android Fabric C++ implementation
Reviewed By: shergin
Differential Revision: D9781846
fbshipit-source-id: 952d72556983955875198ac3b7eece6868bc4ae8
Summary: This diff adds support for image views in Android
Reviewed By: shergin
Differential Revision: D9757712
fbshipit-source-id: 8d33e04c8ac4a670af6ca49bb3b9dccc69d52e40
Summary: This diff fixes the compilation error: "implicit instantiation of undefined template std::hash" when using TextAttributes in Android
Reviewed By: shergin
Differential Revision: D9849407
fbshipit-source-id: 7fcb94b1d4f7715d8037ecbf302d8f345e99e9fd
Summary: This diff introduces the concept of Local Data in Android Fabric C++ and as an example we uses it to implement Text View.
Reviewed By: shergin
Differential Revision: D9583970
fbshipit-source-id: ab7478b16ef4327ff574ca1467870ab9cb684ea0
Summary: In this diff I added support to be able to measure C++ shadowNode in Android. As an example I implemented the measurement of TextViews
Reviewed By: shergin
Differential Revision: D9583972
fbshipit-source-id: 1344782d4c586c94a4576b18a4acfa4775e46952
Summary: This diff introduces a way to convert ParagraphLocalData object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801892
fbshipit-source-id: e50217042a216ea67f28178bb80b136cbb8fb195
Summary: This diff introduces a way to convert AttributedString object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801438
fbshipit-source-id: b762f54917ae90bf53c7f9d07f63b876d1265ece
Summary: This diff introduces a way to convert TextAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9800636
fbshipit-source-id: 592f1cb60a00d3beaecee221259e8914731049d4
Summary: This diff introduces a way to convert ParagrapgAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9798895
fbshipit-source-id: 5b139a079c8681749c3e13938482b47e4153019d
Summary:
A bunch of different things was changed, but the most important (and need) change is that `UIManager` is now passed in the function as a regular reference, not as a `shared_ptr`. Besides that fact that passing this as `shared_ptr` is simply incorrect (because there is no ownership sharing/transferring here), we need this change because we cannot construct `shared_ptr` from `this` inside `UIManager` class (especially in the constructor).
Besides that:
* `const &` everything (correctness, explicit intention, performance);
* Names were unified with the rest of the code;
* `auto` everything;
* All JSI stuff is now explicitly prefixed with `jsi::`;
* `using` instead of `typedef` (modern C++ syntax);
* Lamdas instead of std::bind (same perfromance, much more clear and flexible);
Reviewed By: mdvacca
Differential Revision: D9835901
fbshipit-source-id: 935be0ae889fe5508ffa9498282c939c816587e1
Summary: In modern C++ `const` basically means `thread-safe` and we commit that all that methods are thread-safe.
Reviewed By: mdvacca
Differential Revision: D9836100
fbshipit-source-id: 4241ca80da77338b25246e622cf8d7e8c360eff7
Summary:
The spec says that `bridge_transfer` indicates that we "transfer ownership of the pointer" to ARC which implies that as soon this part of the code does not need the object, it will be deallocated. However, that's not what we want here. This object is actually already owned by another ARC-powered code somewhere else and the pointer to it was transferred as a raw pointer through the C++ world.
So, we want to keep the ownership of the object on the other side but still imply the lifetime of the object. So how can we do that? Simple, we have to use `bridge`.
Why? ARC is not magical, it's just automatic ref counting. And I think the only difference between `bridge` and `bridge_transfer` is how many refcounter's bumps will be added to the generated code. In the case of `bridge_transfer` it is zero, in the case of `bridge` it is one. So, initializing a new Objective-C variable that points to the shared resource we have to bump the counter once, so we have to use `bridge`.
Reviewed By: mdvacca
Differential Revision: D9819405
fbshipit-source-id: 9e7af343917ec4407a64d884402b10ee2a8097f9
Summary: We will need that to manage collections of attributed strings.
Reviewed By: mdvacca
Differential Revision: D9803351
fbshipit-source-id: 0ea9719f97ed30ff6dfe17b6dbebf448afe228b3
Summary: We will need this eventually.
Reviewed By: mdvacca
Differential Revision: D9799852
fbshipit-source-id: 0411e2f41540273c80f425e04c877fe51b9b2374
Summary:
I realized that instead of using shared_ptr's type-erasure feature, we can make the EventHandler's destructor virtual and this itself will allow safe deallocation by a pointer to a base class.
We cannot use the same technic for EventTarget thought because having a weak_ptr to this is another feature of shared_ptr that we need.
Reviewed By: mdvacca
Differential Revision: D9775742
fbshipit-source-id: 3c23a163827e8aa9ec731c89ce87051a93afe4ca
Summary: Instead of relying on explicit `RawEventDispatchable` function, we simply check the existence of the `weak_ptr` to `EventTarget`. This is efficient and sufficient because only an EventEmitter retains an associated EventTarget.
Reviewed By: mdvacca
Differential Revision: D9764858
fbshipit-source-id: 4ac25d925f189d0f8b9002e52388fd51629934a8
Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
Summary:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
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:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
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. `TextShadowNode` represents virtual texts. For the time being, virtual text nodes only need touch capabilities so that they can handle `onPress` events for their children. Therefore, we should set the `TextShadowNode`'s `EventEmitterT` to `TouchEventEmitter`.
2. Since `ParagraphShadowNode` extends an instance of the `ConcreteViewShadowNode` template, it automatically uses the `ViewEventEmitter` if no event emitter is specified. I think it's better to make the event emitter explicitly specified. So, I've included that change in this diff.
Reviewed By: shergin
Differential Revision: D9696906
fbshipit-source-id: ac053ffdde4c2fbc6351f177c07a2ada4445cbb8
Summary: In the future, we may want some components (like Virtual Text) to handle only touch events. Therefore, I've extracted `TouchEventEmitter` from `ViewEventEmitter`.
Reviewed By: shergin
Differential Revision: D9696903
fbshipit-source-id: f6acc90d8ff53b5e6badaa472a5e099fb7cf03ff
Summary:
When a user clicks on some text, `RCTSurfaceTouchHandler` will call into a method on `RCTParagraphComponentView`. That method (i.e: `touchEventEmitter`) would be responsible for identifying the closest ancestral `<Text/>` component to which we should dispatch the `onPress` event, given the point where the user clicked. To answer this query, we'll use a data structure called `UIAttributedString`.
This data structure represents a string, and a corresponding mapping from sequences of its characters to some arbitrary data. In this attributed string, we'll map sequences of characters to their closest ancestral `ParagraphShadowNode` or `TextShadowNode`. That way, when we get a click event on `RCTParagraphComponentView`, we can just look at the character that was clicked, and use that information to do a lookup in the attributed string to find the shadow node who's EventEmitter is responsible for processing the click event.
Reviewed By: shergin
Differential Revision: D9696904
fbshipit-source-id: a199649981ad271afa85414ce4c3f056851348be
Summary: Previously, `BaseTextShadowNode::getAttributedString` used to recurse on a list of `SharedShadowNode`s (i.e: the children). In the `RawText` base case of this recursion, we'll need to record the parent of the current `RawText` (so that we can dispatch the `onPress` event to it). Therefore, we need to start recursing using the `SharedShadowNode` itself, and not its children.
Reviewed By: shergin
Differential Revision: D9696908
fbshipit-source-id: dbf3f9c21a7ae4de421d0355c4e5900b3947dc2a
Summary:
@public
Trivial.
We should not use the name of the effort in the API interfaces where it's not neccecery.
Reviewed By: sahrens
Differential Revision: D9652991
fbshipit-source-id: 52b99e39f92926f9fc99626690eb4385195558f6
Summary:
@public
Now we simply skip `uiManagerDidFinishTransaction` calls if they refer to unregister surfaces. In the future, after we have proper asynchronous scheduling and sync unmounting (and if we chose to have sync unmounting), we can avoid this situation (and assert in this cases).
Reviewed By: sahrens
Differential Revision: D9652731
fbshipit-source-id: e376ea1ae4f93960a903e6397d843bd7c4b72400
Summary:
@public
We don't need this anymore.
The same functionality is now implemented as `ShadowView::operator==` in much more reasonable way.
Reviewed By: sahrens
Differential Revision: D9649821
fbshipit-source-id: 8cd5f3cb4f583fd10d2d1e060aba914541341b5b
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
Empty (nullptr) color should be treated as `Clear` color ({0, 0, 0, 0} - black, fully tranparent), so `colorComponentsFromColor()` was changed to accomodate this (previously it crashed).
Reviewed By: rsnara
Differential Revision: D9631865
fbshipit-source-id: e211f34a89e9f5f86d9fca2789c7163db4feaab1
Summary:
@public
Apparently, it's how it should be.
Reviewed By: rsnara
Differential Revision: D9631870
fbshipit-source-id: 46f58270104d699fbc9abe21062c12f791460536
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
EdgeInsets and CornerInsets are now just qualifications of those generics:
using EdgeInsets = RectangleEdges<Float>;
using CornerInsets = RectangleCorners<Float>;
We will need more concrete types like that in the future diffs.
Reviewed By: mdvacca
Differential Revision: D9614428
fbshipit-source-id: e4d48a11d9083958c3ada68e6368afb150c64f6b
Summary:
@public
Previously, we amitted `default` argument in `convertRawProp` functions assuming that all default values are equal to results of their default constructors (which was something between "wrong" and "lucky coincidence"). Now we use a `YGStyle` default value as a source of all semantic default values of all layout props/styles.
Reviewed By: mdvacca
Differential Revision: D9626469
fbshipit-source-id: 5cfc9c518772556f59da46f608181145cc744928
Summary:
@public
Now it's clear that we don't need to store/handle ShadowTree objects as `shared_ptr`s; Scheduler should own it. This diff changes that to using unique_ptr and removes a base class of ShadowTree.
Reviewed By: mdvacca
Differential Revision: D9403567
fbshipit-source-id: 6e411714b632a04233fd5b25c8ab7cdd260105fd
Summary:
@public
Voalá, this small change actually implements view flattening. Obviously, it does not work right now because there are no `ShadowNode` classes which implement `isLayoutOnly`.
Surprisingly, correct implementing of `isLayoutOnly` is quite tricky, we will work on this in coming diffs.
Reviewed By: mdvacca
Differential Revision: D9403565
fbshipit-source-id: 1f16f912cb5c6841405a1fc3cf36aec28698c11f
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
We need some another object like ShadowNode (but not ShadowNode) to represent an instance of the component in the mutation instructions. This is
the main motivation for introducing ShadowView.
Why not use ShadowNode? ShadowNode is designed to represent a node in ShadowTree, not be a part of a mutation instruction.
* ShadowNode exposes some APIs that should not be exposed to the mounting layer;
* ShadowNode is an immutable data structure, so we cannot mutate it in some way which can be meaningful for mounting;
* We should not add to ShadowNode any functionality which is needed only for mounting;
* ShadowNode is a bit more heavy object to share that it needs to be; it's exposed (embedded into Mutation) as a `shared_ptr` which is not optimal from the performance perspective;
* Retaining ShadowNode from mounting code can unnecessarily extend its lifetime which can negatively affect memory usage.
Reviewed By: mdvacca
Differential Revision: D9403562
fbshipit-source-id: 72ad81ed918157a62cd3d1a03261f14447649d0b
Summary:
@public
Trivial. Those operations are very useful in layout algorithms.
Reviewed By: mdvacca
Differential Revision: D9403566
fbshipit-source-id: e76967aaaac3a36bf6d3e7a468b5ae7769a4dcac
Summary: Unused loads hurt readability and take time to process.
Reviewed By: hramos
Differential Revision: D9494120
fbshipit-source-id: 455b56efadab1cb976344cffcb427772bfda2f71
Summary: This diff implements the HorizontalScrollView component for Android Fabric C++, as part of this diff I also re-named the components AndroidHorizontalScrollContentView for RCTAndroidHorizontalScrollContentView and AndroidHorizontalScrollView for RCTAndroidHorizontalScrollView. This might sound against our plan of removing the RCT preffix, but it is to make it simpler to map components between current implementation of RN and Fabric (otherwise we don't know when to add the RCT preffix in Android side to find the right View Manager), later we can just remove the preffix from C++, Android, iOS and JS.
Reviewed By: shergin, achen1
Differential Revision: D9122729
fbshipit-source-id: e9299552857c6dd0c18abfa5fa49a3d50e221729
Summary:
@public
Now, one of the main purposes of `EventEmitter`s is to create RawEvent instances for all specific event invocations.
Reviewed By: mdvacca
Differential Revision: D8886226
fbshipit-source-id: 82a489174efcda097887e70650a2038dc986d149
Summary:
@public
Now, it's not just an abstract class, it's a regular class which unifies event delivery priorities using specific event beats and event pipe.
Reviewed By: mdvacca
Differential Revision: D8886232
fbshipit-source-id: c4360511e5fd477ca7407fc3ebbd99ca578e79cc
Summary:
@public
The existing code does not use that at all but we need that for testing things and we will need this in the future.
Reviewed By: mdvacca
Differential Revision: D8886236
fbshipit-source-id: 5ca33e4f4d4ca13a6be0f55cc04b59d5f9b27fa9
Summary:
@public
We need that to ensure that we will not deliver events to nodes with invalid state.
Reviewed By: mdvacca
Differential Revision: D8886234
fbshipit-source-id: 1d6ca129c97a5dca0411e85909aea48185f46c54
Summary:
@public
Instead of having two methods it's easier to have just one which can be abstracted as `EventPipe`.
Reviewed By: mdvacca
Differential Revision: D8886231
fbshipit-source-id: af9fd92dc4afa1219a11acce0aa021a85c94d232
Summary:
@public
EventQueue is a queue of events that synchronizing event dispatching with given Event Beat.
The only difference between UnbatchedEventQueue and BatchedEventQueue is that UnbatchedEventQueue `induce` an Event Beat right after enqueing an event.
Reviewed By: mdvacca
Differential Revision: D8886225
fbshipit-source-id: fedba6fdff2ecb6f3c615cea09b5fdaa58890479
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: This diff implements the update of props in Fabric C++. The props values are passed to java in a ReadableMap and they are integrated into the current implementation of ViewManagers. In the fututre we will replace the ReadableMap for typed objects.
Reviewed By: shergin
Differential Revision: D9093560
fbshipit-source-id: da58326cfadb0665dac3349a8cf24cde2d401aaa
Summary: this diff exposes the rawProps folly::dynamic map received by JS as part of the Props class
Reviewed By: shergin
Differential Revision: D9093559
fbshipit-source-id: 5f5bc4924aebb6bcc24c7a82ce1a59593d44450e
Summary: This diff fixes the color conversions for Android
Reviewed By: shergin
Differential Revision: D9093561
fbshipit-source-id: a17e61c58be511bd463dc0b21b632dc24066b8b6
Summary: This diff improves the error message that is displayed when a component descriptor is not implemented in C++
Reviewed By: shergin
Differential Revision: D9093562
fbshipit-source-id: 930b381bc66c20af6fa160b09e7484bad4666e28
Summary:
@public
Now it accepts `const ShadowNode &` instead of `std::shared_ptr<const ShadowNode>` which is more reasonable (and more performant) becasue the function must not retain ownershipt.
Reviewed By: mdvacca
Differential Revision: D9073921
fbshipit-source-id: c24c475615e0f81b3e004e118dea7565d8e757b4
Summary:
@public
We backported that into Yoga recently, so we don't need it here anymore.
Reviewed By: mdvacca
Differential Revision: D8988439
fbshipit-source-id: 01a538ff291e25d92eeb01b1fdee3a6868b2448b
Summary:
@public
To avoid unnecessary copying of `shared_ptr`s inside ShadowNodeFragment, now we store them as `const &` references.
Reviewed By: mdvacca
Differential Revision: D8988388
fbshipit-source-id: 0b3582e57ce7577b8fa819392bf33f34e1a60b59
Summary:
@public
Now we use same data structure to specify a shape of shadow node as we use in ShadowNode (sub)clases.
Reviewed By: mdvacca
Differential Revision: D8988387
fbshipit-source-id: 475298b2c71ee7ee2b197db009f7b8313b54f5df
Summary:
@public
When we copy-construct ShadowNode, we don't need to retain a source shadow node, so there is no need to pass it as a `shared_ptr`. Passing an argument to constructor as `const &` is also more idiomatic in C++.
Reviewed By: mdvacca
Differential Revision: D8988384
fbshipit-source-id: 1279d9185fa1b4b82fd26e3040bd62fa9495b4d3
Summary:
@public
ShadowNode class is designed to share `props` and `children` objects between instances. Given that all *Props classes are immutable, it's very easy to share them and we do this from the day one. The `children_` collection is more tricky though because ShadowNode class has a couple of mutation methods. Previously, we dealt with it very simply by copying the whole vector in constructors, and that was far from optimal. Now we store a special flag that indicates that the children list is shared among nodes, and we clone this before the first mutation.
Sharing a `shared_ptr` should be much more efficient (cost of atomic refcount increment) than instantiating whole new collection (an allocation).
Reviewed By: mdvacca
Differential Revision: D8988386
fbshipit-source-id: cb2f6b2fccac70a35e070a1aa108d135f77cd041
Summary:
@public
Just a type alias to make the code prettier, nothing more.
Reviewed By: mdvacca
Differential Revision: D8988383
fbshipit-source-id: 3f21de0ec0cb9a2270eccfc4a67a3d1108535e42
Summary:
@public
This diff changes a way how we specify a shape of newly created and/or cloned of ShadowNode. Previously we pass those values as a list of arguments, now those values are coupled into a new data structure called ShadowNodeFragment. All that makes suppose to make code much more easy to read and maintain, this is especially important because we want to add a couple of new entities in this set.
Reviewed By: mdvacca
Differential Revision: D8988389
fbshipit-source-id: 1835f646e1ecc6a1f413feaf1900f3d3ad0ebc05
Summary:
@public
Previously, all ConcreteShadowNode subclasses had to override `getComponentName()` function to specialize a name of the component. And often it was all that those subclasses do. Now, it's a template argument; and many ShadowNode classes can be created as oneliners via *just* specializing ConcreteShadowNode template.
Unfortunately, C++ does not allow to use `std::string`s or string literals as template arguments, but it allows to use pointers. Moreover, those pointers must point to some linked data, hence, those values must be declared in .cpp (not .h) files. For simplicity, we put those constants in Props classes, (but this is not a strong requirement).
Reviewed By: mdvacca
Differential Revision: D8942826
fbshipit-source-id: 4fd517e2485eb8f8c20a51df9b3496941856d8a5
Summary:
@public
Now, Sealable is already error-preventing-only mechanism, no business logic relies on that.
So, it makes sense to make it debug-only to illuminate possible performance impact.
Reviewed By: mdvacca
Differential Revision: D8923597
fbshipit-source-id: 80aa9097c4b719e91de73ac59f38d3a4751f0b06
Summary:
@public
Previously, ContextContainer could store only `shared_ptr`s, but now it wraps all values in own `shared_ptr` container.
I wish we can use `unique_ptr` here, but apparently we cannot because `unique_ptr` does not support type-erasure (`std::unique_ptr<void>` is illigal).
Becasue ContextContainer is not supposed to be used in hot paths, the performance aspect of that does not actually matter.
Reviewed By: mdvacca
Differential Revision: D8853446
fbshipit-source-id: e5d0a5595fe44c59f1395d6ffccf9d3fed923c83
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
We don't need to maintain an order of this collection, so using `unordered_map` is more appropriate.
Reviewed By: mdvacca
Differential Revision: D8826946
fbshipit-source-id: f6890097cc5d6a1e06f6b2cfd1b7d68a388da461
Summary:
@public
We need this in case when we want to store several intances of the same class in the container.
Reviewed By: mdvacca
Differential Revision: D8814808
fbshipit-source-id: 78ab15d78cf3878d03bf0a45bc42b968d87435e7
Summary:
@public
In most cases callsite knows probable index of replacing child node, hence it makes sense to provide this info to `replaceChild` to illuminate O(n) search in most cases.
Reviewed By: mdvacca
Differential Revision: D8814809
fbshipit-source-id: 0edf82878a72260365e2757beb3886ad07c7464d
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
On Android, a color can be represented as 32 bits integer, so there is no need to instantiate complex color objects and then pass them as shared pointers. Hense instead of using shared_ptr, we use a simple wrapper class which provides a pointer-like interface.
Reviewed By: mdvacca
Differential Revision: D8742014
fbshipit-source-id: 14109b61fd84a34989538a15bc6fe4e2a8ce83a6
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
There is no reason to have it inside View; it deserves that.
Reviewed By: mdvacca
Differential Revision: D8757012
fbshipit-source-id: 881b54008b51614cd203ab97811494fa7c30e4ef
Summary:
@public
Quite trivial. We had to have this from the day one.
We don't need cache invalidation policy because all subtree is immutable.
Reviewed By: mdvacca
Differential Revision: D8709973
fbshipit-source-id: bd7fcf0ae1dcb23894321cb5d16da18cb1ab788f
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
* In case of `ShadowTree` we just pass original old node as a `commit` method argument;
* In case of `ConcreteViewShadowNode` we just don't need that because diffing algorithm does not use that information anymore.
Reviewed By: mdvacca
Differential Revision: D8753906
fbshipit-source-id: b8555083c7e72e9b3c0f9a8065745946d4cf44c7
Summary:
@public
Non-null owner pointer in Yoga node indicates that this node is already being used by some other subtree, so it must be cloned in case of possible (re)layout.
Theoretically, this node must/can be cloned by Yoga right before applying a new layout to this node, but Yoga has a special optimization that uses that fact that Yoga always cloning *all* children of a particular node altogether. This is not true for React; to meet React and Yoga worlds we double check the owner pointer in `addChild` and clone node preliminary if needed.
See also the previous diff for more context.
Reviewed By: mdvacca
Differential Revision: D8709952
fbshipit-source-id: 84ef0faa0f1d9cc9a8136b550cf325bc20508d53
Summary:
It's wasteful to do it by value. I'm fairly sure this is
safe, especially because
fbd332dee8 (diff-ade2a4bbd6582e2898cbd9e0fa142ab5R215)
shows that we did access by reference before.
Reviewed By: priteshrnandgaonkar, davidaurelio
Differential Revision: D8822697
fbshipit-source-id: 791bcf0fa37453f67795af727c85c8adce3b0f69
Summary:
@public
... and it's as efficient as it was before.
The previous version of the algorithm used `sourceNode` reference to know the previous state of the node to call the algorithm recursively.
That wasn't so good because of several reasons:
- It was fragile because we had two different sources of the truth of the "previous state of the tree": committed tree and source node pointer;
- We had to store weak pointers to source nodes inside cloned nodes. That is not free in terms of performance;
- The old approach introduced a constraint that all previously used and now reinserted nodes must be cloned to update source node (otherwise, the algorithm would regenerate instructions recreating already existing subtrees);
- That cloning required access to `isSealed` flag which is supposed to be a debug-only thing (that actually affects performance and must be compile-out for release builds).
The new approach compares nodes with same react tag and naturally cloning-artifacts resilient.
Yes, the new approach uses a map of inserted nodes, but the previous one already had it (otherwise there is no way to tell which nodes should be "deleted"). And anyway, this is a very little map that exists for a very little period of time.
Reviewed By: mdvacca
Differential Revision: D8709953
fbshipit-source-id: 027abb326cf45f00f7bb0bbd7c4e612578268c66
Summary: Revert the order of "remove mount items", to ensure views are removed from high index to low index.
Reviewed By: shergin
Differential Revision: D8742796
fbshipit-source-id: 6e04c39386d290bf3958ee83256d4fbe23e2c4ca
Summary: We were supposed to pass in proper eventEmitter, but passed in one with null eventTarget instead, causing assertion failures when dispatching event.
Reviewed By: sebmarkbage, shergin
Differential Revision: D8720793
fbshipit-source-id: 891f3b2a2c76a6dd3e40039623c6e86991aad50b
Summary:
@public
This compiles, but it works only on iOS for now.
Reviewed By: mdvacca
Differential Revision: D8655540
fbshipit-source-id: 7e9a73fadb317dd62298af6f347344ac4229a8a5
Summary:
@public
This compiles but this does not work.
To make it actually work we have to implement all missing functions in `Color.cpp` and co.
Reviewed By: fkgozali
Differential Revision: D8655537
fbshipit-source-id: 564fb7131445af81cf05407239dc6ba870cf6b83
Summary:
Removes the concept of instance handle. Instead we pass the event target
to createNode and don't pass it to subsequent clones.
The life time of the event target is managed by native (the event emitter).
It has to be released manually.
Reviewed By: shergin
Differential Revision: D8688330
fbshipit-source-id: e11b61f147ea9ca4dfb453fe07063ed06f24b7ac
Summary:
@public
Most of them are legit issues which should not be compilable anyways (but Clang tolerates thems).
Reviewed By: mdvacca
Differential Revision: D8655539
fbshipit-source-id: 645729fb9d6a120ce1ab2b07542abcdacd72320d
Summary:
@public
Suddenly, it is not supported on Android.
Luckelly `folly:to<std::string>()` is as good as `std::to_string()`.
Reviewed By: mdvacca
Differential Revision: D8655538
fbshipit-source-id: 2b3b970f6a261253aaa6b22dba8338dc66b7195d
Summary:
@public
This is follow up for D8601600 and D8247652 (the last one has detailed explanation of the problem).
From this commit I propose that we have to follow simple rule:
If some prop has a default value which differs from the default value of its type, we have to specify it as {<value>} in .h file and explicitly in .m file, for all other props the default value must not be specified explicitly (in .h files it must be specified as {}).
The reason is that we have to embrase those cases and establish behaviour: if we change the default value in .h file, it always means that we have to change the value in .cpp file too.
Reviewed By: fkgozali
Differential Revision: D8601776
fbshipit-source-id: 3379aace4e2d72febb2b942a3da1cb24decf54be
Summary:
@public
Otherwise, it can mess with implementation for `int`s and causes some errors where `float` implementation was requested but `int` was applied.
Reviewed By: mdvacca
Differential Revision: D8601752
fbshipit-source-id: cfe51b7785ff29ee4ad88f0f1cbfed335557d5ef
Summary: This is basic impl of <PerformanceLoggerFlag> component without any layout/mounting computation, just TTI.
Reviewed By: shergin, mdvacca
Differential Revision: D8598983
fbshipit-source-id: b938753d6396088735cbbeab26d69c9aaa45608e
Summary:
@public
It fixes a problem when some Views got disaper after they have non-zero opacity.
Reviewed By: mdvacca
Differential Revision: D8601600
fbshipit-source-id: 3da3ee591d4a685a8d7a56b15519d4d5cae4a031
Summary:
@public
The current Fabric architecture, in general, does not support "subscribing" for events, so all kinds of events are always delivered no matter have JavaScript components `on`-handlers for them or not.
At this point, we are not sure should it be this way or not. But we are sure that for some extremely noisy events (like onLayout) we have to make an exception right now (otherwise overall performance will suffer).
So, this diff implements that for `onLayout`.
Reviewed By: fkgozali
Differential Revision: D8597408
fbshipit-source-id: 6933b7cb96e24f0660bd7850b625ff27e3146a2b
Summary:
@public
We do preventing cloning in UIManager especially to add a layer to Shadow Node source chain,
so apparently there is no point illuminate that by calling `shallowSourceNode`.
Reviewed By: fkgozali
Differential Revision: D8585163
fbshipit-source-id: 3743edc30bf2183c420fd79ce1e59d68ceaa278b
Summary:
@public
We need this temporary for testing until we support them all.
Reviewed By: mdvacca
Differential Revision: D8552361
fbshipit-source-id: 25f48cebcf5a665a24b92803dd7738f947ca74b2
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
If some prop has `std::vector` type, it possible that on JS side we want to pass just one element of the array.
And in this case we sometimes drop array initialization (`[]`) part, so instead of passing `[{x:1, y:1}]` we pass `{x:1, y:1}`.
This diff adds support for that.
Reviewed By: mdvacca
Differential Revision: D8526572
fbshipit-source-id: 33d4369ac48cac3eb1c534f477d8259e76e0c547
Summary:
@public
This diff implements basics of cross-platform part of <Image> component.
Known issues:
- Events does not work yet.
- Some quite specific image source parameters (like custom http headers) are not supported yet.
Reviewed By: fkgozali
Differential Revision: D8526575
fbshipit-source-id: ecc97d9fda2b2e65bb1b079af057f8e176a161e5
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
This diff changes how we store and manage Yoga Config in layoutable shadow nodes.
Previously we have `shared_ptr` to single shared yoga config (one to many relationships); now we initiate and store yoga config with yoga node (one to one relationship).
Cons:
- Less memory efficient.
Pros:
- Much more flexible model. Configuration can be tweaked on a per-node basis.
- More performant. Dealing with `shared_ptr` is expensive because of atomic ref-counter. (This is not really applicable for the previous approach but would be applicable for any alternate approach where we want to have more granular control of the configuration.) Data locality is also great in the new model which should positively impact performance.
- Simplicity. Any alternate approach where we manage sets of nodes which share the same configuration is going to be quite complex.
Reviewed By: fkgozali
Differential Revision: D8475638
fbshipit-source-id: 5d73116718ced8e4b2d31d857bb9aac69eb69f2b
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
There are some race conditions between VM objects getting deallocated and the instanceHandle held by the eventEmitter can point to deallocated memory space, causing undefined behavior like a crash.
For now, keep a strong ref to the eventTarget inside EventEmitter to avoid that scenario. This is a temporary workaround.
Reviewed By: shergin
Differential Revision: D8576785
fbshipit-source-id: 87ef36f716270ceca906b32bb86e0046ceaca19e
Valentin Shergin
David Aurelio
Amir Shalem
David Vacca
Spencer Ahrens
Rick Hanlon
Taras Tsugrii
Doug Russell
Kevin Gozali
empyrical
Uladzislau Paulovich
Lucian Grijincu
Tim Yung
Scott Rice
Héctor Ramos
Ramanpreet Nara
Joe Peplowski
Jonathan Kim
Scott Wolchok
Sebastian Markbage