Summary:
This diff contains some small improvements in `ImageResponseObserverCoordinator` which are pretty minor:
* Now we use `small_vector` instead of a normal one. In the vast majority of cases, the coordinator has only one observer, so having `small_vector` with default size `1` saves us a memory allocation (which is a dozen of allocations for a screen, not bad).
* Empty constructor and destructor were removed.
* Unnecessary copying of ImageResponse was removed. ImageResponse is a practically a shared_pointer, it has value semantic and does not need to be copied. We don't need to acquire mutex to access that.
Reviewed By: sammy-SC
Differential Revision: D17368740
fbshipit-source-id: 828e27a72b9c8ac0063c5fbda00f83ddb255309c
Summary: Now that all the plumbing is done, this diff finally implements async method dispatch on the NativeModule thread.
Reviewed By: mdvacca
Differential Revision: D17480605
fbshipit-source-id: 992aab99954c488a0327144d84a1668a2b158d04
Summary:
Self explanatory.
1. **Existing:** We create the NativeModules thread in CatalystInstanceImpl.cpp.
2. D17422165: We wrap this thread in a `BridgeNativeCallInvoker`.
3. D17422164: We use `CatalystInstanceImpl::getNativeCallInvokerHolder()` to get a hold of the `BridgeNitiveCallInvoker` in Java.
4. D17422163: From Java, we pass this `CallInvokerHolder` to `TurboModuleManager`'s constructor.
5. **This diff:** `TurboModuleManager` then unwraps the `CallInvoker` from `CallInvokerHolder`, and passes it to all TurboModules in their constructor.
Reviewed By: PeteTheHeat
Differential Revision: D17422160
fbshipit-source-id: c0a76dfe5fdedac2e0e21f7a562bc7588dc190fb
Summary: This abstraction will be used by TurboModules to schedule work on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17422165
fbshipit-source-id: d5ca7837a0ecbcc2118813e1bafa6d445ba2ef3b
Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
If you try to use ART components with fabric, their transform is causes crash (stack trace P108110438). You can see this crash if you use RCTVideo component in fabric and tap video to reveal slider.
The cause of crash is mismatch of formats between what is expected for transform and what is being sent.
In this diff we add a check to see whether the configuration is of expected type.
Reviewed By: shergin
Differential Revision: D17181838
fbshipit-source-id: c4f3c920281a2e7f58ff0ffe1d0ec2af8249a16c
Summary:
Merging react-native-windows to 0.60 - the visual studio compiler seems to take issue with the existing code
## Changelog
[Internal] [Fixed] - Build fix for react-native-windows (MSVC)
Pull Request resolved: https://github.com/facebook/react-native/pull/26462
Test Plan:
No real change, just making compilers happy.
### Side Note
We'll want this change cherry-pickered to RN 0.60 and RN 0.61 so users of react-native-windows dont have to use our fork of react-native.
Reviewed By: mhorowitz
Differential Revision: D17406081
Pulled By: TheSavior
fbshipit-source-id: bc056e1a545c6478fdcbd5645f3a8dea657162c8
Summary: This is just a minor fix to D17380360. Basically, we want to make sure that callbacks can only be called once on the ObjC side.
Reviewed By: fkgozali
Differential Revision: D17403852
fbshipit-source-id: b0d2bbd539daef4837a345bc2953dd9687b3147b
Summary: There is a race condition between tearing down the bridge vs CallbackWrapper invoking the wrapped jsi::Function. This means the wrapper can be stale and unsafe to access after the bridge dies. To avoid unsafe access, let's clean it up properly using weak ref.
Reviewed By: RSNara
Differential Revision: D17380360
fbshipit-source-id: f91ce75d945bf8ed0b141c593bcc674ff465aa8c
Summary:
`getHeapInfo` was creating and return a `jsi::Object`. This object was not being traced
when API tracing was turned on.
This resulted in a bug in synth traces, an object was being acted upon without its creation source
being logged.
In order to prevent this, change the API of `getHeapInfo` to no longer return any objects, or modify other heap
contents.
This is preferable to having `TracingRuntime` attempt to mimic the operations of two different implementations.
## Changelog:
[Internal] [Changed] - Changed `jsi::Instrumentation::getHeapInfo` to use a `std::unordered_map`
Reviewed By: mhorowitz
Differential Revision: D17273235
fbshipit-source-id: f69860dcc524c2cf501746a41dbac20b4db8c456
Summary:
This diff improves on D17244061 by moving the `Jni::JniLocalScope` to earlier on in `JavaTurboModule::invokeJavaMethod`. The problem with D17244061 was two-fold:
1. It completely ignored the local references created by just calling `getConstants()`. So, you could spam `getConstants()` and still get an overflow.
2. The capacity was incorrect. Basically, two things happen when you call `PushLocalFrame`. One, we push an actual Jni frame onto a stack somewhere in the dvm: https://fburl.com/f16wfrxi, https://fburl.com/jhpha563. Popping off this stack is how the local references are cleared when we call `PopLocalFrame`. Two, we do a check to make sure that we can support at least `capacity` more local references: https://fburl.com/jucvew8j. The max is 512. The problem before was that, I was just using the argument count for the capacity. This was inaccurate because we create many `jclass` objects, and several misc. intermediate java objects when we invoke `JavaTurboModule::invokeJavaMethod`. So, I've refined the calculation of capacity to be a bit more accurate. This should make sure that capacity check works, which should help us fail faster if our local reference count approaches 512.
Reviewed By: shergin
Differential Revision: D17337354
fbshipit-source-id: 45574bae4748c52d8f919c1480b9a0936d970628
Summary: Include <cstdarg>, which defines the va_start and va_end macros.
Reviewed By: tmikov
Differential Revision: D17344433
fbshipit-source-id: f51fb53cc6e016eeef1a9270c1f2c468a5edc967
Summary:
Managed to get fabric building in my app. Here are the changes needed in the podspec.
There were other issues with codegen but it would be too involved to fix for now. This is a good first spec to get it working better in OSS.
## Changelog
[iOS] [Fixed] - Add some missing dependencies to the fabric podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/26197
Test Plan: Managed to get fabric building in a project.
Reviewed By: cpojer
Differential Revision: D17091504
Pulled By: osdnk
fbshipit-source-id: a5d0c46899e342e07ceafc2e4514a03fabf1471d
Summary:
This diff changes the value of `EmptyLayoutMetrics` to make it as unusual and useless as possible. This helps when we need to compare sub-values of `LayoutMetrics` to apply only changed ones.
For example, let say we need to make a transition between two `LayoutMetrics` values. Let's say the first (the source) one equals `EmptyLayoutMetrics`. In order to apply only changed part, we need to compare individual sub-values, like `frame` or `displayType`. Before this change, the default value of `borderWidth` was `{0, 0, 0, 0}`. So in case if the second (the destination) value is also `{0, 0, 0, 0}`, the operation will be skipped.
This is undesirable because all new values have to be applied anyway because `EmptyLayoutMetrics` designates that the actual previous values are unknowns.
This fixes some visual issues on iOS caused by this issue because recycled views sometimes have non-default layout values where the transition from `EmptyLayoutMetrics` to some arbitrary value skips some sub-values.
Reviewed By: JoshuaGross
Differential Revision: D17312176
fbshipit-source-id: 7f311baea202ec2662ca87be0ae0ae6c6dd42712
Summary:
Because we use the `PromiseWrapper` struct, we need to explicitly manage its lifecycle to ensure that it doesn't clear before the promise methods are invoked by the ObjC Runtime. This `PromiseWrapper` struct is unnecessary. We could just not have it and create the CallbackWrappers for resolve and reject within the `createPromise` function. Therefore, I moved all the logic from `PromiseWrapper` to the `RCTTurboModule::createPromise` function.
In the next diff, I'm going to keep a track of all the CallbackWrappers we create in instances of RCTTurboModule, and `destroy()` them in the destructor of RCTTurboModule. This should make sure that all `jsi::Function`s are released before we delete the `jsi::Runtime`, which should prevent Marketplace from crashing when we hit CMD + R. See: https://fb.workplace.com/groups/rn.support/permalink/2761112713937326/.
Reviewed By: fkgozali
Differential Revision: D17208729
fbshipit-source-id: ce80c9c01088f0e3dc47c7c29397b7a197d699ce
Summary:
When doing RN init from scratch for 0.61, I noticed pod install was failing. This was because "Yoga.podspec" was mis-spelled to "yoga.podspec" in the yoga ReactCommon folder. Thus, `pod install` was failing
```
[!] No podspec found for `Yoga` in `../node_modules/react-native/ReactCommon/yoga
```
## Changelog
[iOS] [Fixed] - Fix Yoga.podspec case sensitivity
Pull Request resolved: https://github.com/facebook/react-native/pull/26360
Test Plan: `pod install` now runs successfully with a clean build of master.
Differential Revision: D17314027
Pulled By: cpojer
fbshipit-source-id: 8db2ac4dd9295afcc0e074c842dcda71b7b3b668
Summary:
Remove cxx from iOS project, because we have the corresponding implementation in iOS. Otherwise, it would break the logical handling of iOS part.
## Changelog
[iOS] [Fixed] - Remove cxx from iOS project
Pull Request resolved: https://github.com/facebook/react-native/pull/25392
Test Plan: Fabric enabled Tester can work like loading image.
Reviewed By: mdvacca
Differential Revision: D17285463
Pulled By: shergin
fbshipit-source-id: b414406578dcce51f3b54fd06941225efc560e7f
Summary:
The code is moved from the destructor a separate method that we now call in the Scheduler::stopSurface.
That makes the code more readable and resilient to possible races and ownership-related changes.
Reviewed By: JoshuaGross
Differential Revision: D17272294
fbshipit-source-id: 948d76d074577beb3dda6defdf09261b5c8abb98
Summary:
MountingCoordinator is a borderline between Core and Mounting. Some of Core design constraints are impossible/impractical to enforce on Mounting layer, so we have to handle all of those cases in `MountingCoordinator`.
One of the constrains is that all ShadowNodes implicitly depend on associated ComponentDescriptor instances without retaining them (retaining is expensive and creates a retain cycle).
The problem is that the Mounting layer can call `MountingCoordinator::pull()` at any moment (even after the whole Core is already destroyed). To prevent this, the owner of a `MountingCoordinator` on the Core side calls `revoke()` right before being deallocated (right before the moment the owner cannot guarantee the constraint).
Reviewed By: JoshuaGross
Differential Revision: D17272295
fbshipit-source-id: ba8b02eab8f84cce68aa65c1ad36950cd2498049
Summary: Whenever we invoke a method, we convert JS arguments into JNI objects. These JNI objects are all local references that need to be manually destroyed after the method call happens. Therefore, I'm using `JniLocalScope` to automatically do this whenever the stack is cleared after the call to `JavaTurboModule::invokeJavaMethod`. This should hopefully get rid of the JNI table overflow we're seeing in T52817336.
Reviewed By: mdvacca
Differential Revision: D17244061
fbshipit-source-id: 92ca78cdb23ad8dfe2425db46e086c10c9662fe2
Summary:
We're trying to build react-native on Windows (part of the Microsoft\react-native-windows project) with MSVC compiler with WITH_FBSYSTRACE set to true (to route the traces to ETW). This change is to fix a compilation error due to the non standard usage of ATOMIC_VAR_INIT macro called with no parameters. It's not absolutely clear to me the objective of this macro in the standard at all (to be used in c context ?), and which compiler does support this parameterless version (gcc?).
Also, I'm more inclined towards changing the statement to just "std::atomic_uint_least32_t m_systraceCookie{};". Please confirm.
## Changelog
[General] [Fixed] - Removing the non-standard usage of ATOMIC_VAR_INIT macro from code with systrace enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/26238
Test Plan: Build verification should suffice as there is no semantic change introduced by this change.
Differential Revision: D17259213
Pulled By: cpojer
fbshipit-source-id: 9fe44f9220f18399a58f94f0f01d5fa93e6458e0
Summary:
Fixes typos in code comments about CocoaPods’s `use_frameworks!`.
## Changelog
[Internal] [Fixed] - Fix typos in comments about `use_frameworks!`
Pull Request resolved: https://github.com/facebook/react-native/pull/26381
Test Plan: Considering this only changes code comments, I don’t think this pull request needs a test plan.
Differential Revision: D17258856
Pulled By: cpojer
fbshipit-source-id: fd9a7253ef9744685c233ebbec7df9eea50a8d28
Summary: When you return null or [NSNull null] from a TurboModule method, we should just return null to JS.
Reviewed By: fkgozali
Differential Revision: D17141170
fbshipit-source-id: a73410b7a4a765750a8dd9c4e904046ffe1c0fc1
Summary: Adds support for dynamic value that are `std::vector<std::vector<RawValue>>`
Reviewed By: shergin, mdvacca
Differential Revision: D16936932
fbshipit-source-id: fc8d087f9705af9da56ccc1bd9a0537b2bfeb50d
Summary: We used this mechanism at the very early stages of Fabric. Now we do component registration differently.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17200952
fbshipit-source-id: 16ff9d6569714a24e2a8d58dc6e60ad4d7bc1e16
Summary: This allows to implement `findNodeHandle` in Fabric world (temporary).
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175953
fbshipit-source-id: c88bd1c58608450812799d4ecb4a6bf2c027c5f3
Summary: The mehtod implements the core functionality of finding a shadow node by given tag.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175955
fbshipit-source-id: 5cfbb80b2d4e54a33ca9c20a21988df4de54c800
Summary: The new methods provides a way to iterate over all registered shadow trees.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175954
fbshipit-source-id: e4e6ee5a0e0a4e4e36b99d546f8724b99559c8c2
Summary:
Fix Android gradle build error for native debug build.
`NATIVE_BUILD_TYPE=Debug ./gradlew :ReactAndroid:installArchives`
The root cause is `folly::Future<bool>` not declared.
As we don't include true folly::Future implementation in OSS build but to use a forward declaration,
the fix is pretty much like to original declaration as `folly::Future<folly::Unit>`.
## Changelog
[Android] [Fixed] - Fix compile error for native debug build
This change could be ignored from changelog which is only for internal development.
Pull Request resolved: https://github.com/facebook/react-native/pull/26248
Test Plan: Makes sure `NATIVE_BUILD_TYPE=Debug ./gradlew :ReactAndroid:installArchives` build without errors.
Differential Revision: D17169696
Pulled By: mdvacca
fbshipit-source-id: 42e8b84b7ee0d1bd99d913702df98bc030965f63
Summary:
This diff fixes a redbox happens on every single hot-reload practically saying that ImageLoader is misconfigured. The issue happened because after reloading Fabric used the previous obsolete instance of `ImageLoader` created and stored inside old (and already destroyed) instance of Bridge. The fix is simple: We update all dependencies after the Bridge was reloaded.
See https://fb.workplace.com/groups/rn.support/permalink/2677343372314261/ for more details.
Reviewed By: mdvacca
Differential Revision: D17173702
fbshipit-source-id: 5ff0c418feae10ede9b76c184cd24ad06ee008b7
Summary:
We don't need to have those methods virtual anymore.
Nowadays we have a pointer to a `ComponentDescriptor` in `ShadowNode`, it's simpler to get that value from there.
That's also more code-size friendly because we now can remove those methods from a template.
Reviewed By: sammy-SC
Differential Revision: D17142173
fbshipit-source-id: 9f54fbe6c1ebad3ed49843ed75a01ca5ee48c34f
Summary: We merge `events` module into `core` long time ago, so we don't need this anymore.
Reviewed By: mdvacca
Differential Revision: D17142174
fbshipit-source-id: 6e63f7f22dc3d65ed2f9cc3bd4f4776404dfe788
Summary:
This fixes an error when using RN's version of yoga with Flipper.
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Taken from https://github.com/facebook/yoga/blob/master/Yoga.podspec#L25
## Changelog
[Internal] [Fixed] - Add `DEFINES_MODULE=YES` to the yoga podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/26276
Reviewed By: priteshrnandgaonkar
Differential Revision: D17149819
Pulled By: axe-fb
fbshipit-source-id: 5060b8e7111ba411f6e26e3479ad4fb55a552b4e
Summary:
The type is wrong in the constructor.
build-break
Differential Revision: D17145039
fbshipit-source-id: f6b80e38c05e60f04d029aa34baa0c55c237a39a
Summary: Support existing, backwards-compatible AndroidTextInput component for minimal support of TextInput on Android.
Reviewed By: shergin, mdvacca
Differential Revision: D17086758
fbshipit-source-id: 25726f22229e0d5dfe96eb36b386a5317601283d
Summary:
The purpose of `EventBeat` is handling an asynchronous callback to itself which is being delivered on some different thread. That brings a challenge of ensuring that the `EventBeat` object stays valid during the timeframe of callback execution. The concept of Owner helps with that.
The owner is a shared pointer that retains (probably indirectly) the `EventBeat` object. To ensure the correctness of the call, `EventBeat` retains the owner (practically creating a retain cycle) during executing the callback. In case if the pointer to the owner already null, `EventBeat` skips executing the callback.
It's impossible to retain itself directly or refer to the shared pointer to itself from a constructor. `OwnerBox` is designed to work around this issue; it allows to store the pointer later, right after the creation of some other object that owns an `EventBeat`.
Reviewed By: JoshuaGross
Differential Revision: D17128549
fbshipit-source-id: 7ed34fd865430975157fd362f51c4a3d64214430
Summary:
Seems it's more logical and safe to store ShadowTreeRegistry in UIManager than in Scheduler. We also probably will move some functionality dealing with the registry to UIManager.
But most importantly we need it to manage the ownership properly. UIManager might overlive Scheduler and still get a call to process a shadow tree. In the current configuration, it causes a crash because the registry owns by Scheduler. Moving that to UIManager solves that.
Reviewed By: JoshuaGross
Differential Revision: D17128550
fbshipit-source-id: e6735acaa11f2ed82ca17f18a45e389d79aa1a08
Summary:
This diff changes the way how `UIManager`, `UIManagerBindging`, `Scheduler` and `EventDisaptcher` refer to each other which should help with stability and reliability.
Here is the node that describes the details:
# Retaining dilemma
# Players
We have many logical of moving pieces but most of them can be abstracted by following high-level components.
* **Scheduler**
`Scheduler` is the main representation of running React Native infrastructure. Creation of it means the creation of all React Native C++ subsystems (excluding RuntimeExecutor) and destruction of that means the destruction of all dependent parts. Both processes must be thread-safe.
* **UIManager**
UIManager is a module that contains the most high-level logic of managing shadow trees. All React Renderer calls are practically implemented there.
* **UIManagerBinding**
UIManagerBinding is a representation (aka `HostObject`) of UIManager in the JavaScript world.
* **EventDispatcher**
EventDispatcher is a class that implements all logic related to dispatching events: from calling event on any thread anywhere to executing a particular JavaScript handler responsible for handling that event.
Instances of those classes have complex relationships in terms of owning each other, order of creation and destruction. The configuration of these relationships is dictated by a set of constraints that those classes need to satisfy to be constructed, accessed, and destructed in a hostile multithreaded environment. Messing with that can cause deadlocks, random crashes, suboptimal performance or memory leaks. Make sure you consider all constraints and requirements before changing that.
# Goal
We need to have a safe and reliable way to construct and destroy those objects (on any thread, in any random moment). Keep in mind that all of those objects are being accessed from random threads and have random states in any particular moment. Switching threads happens all the time, so having some state in one place does not guarantee any state in other places.
# Caveats
Let's discuss all concrete constrains that the moving pieces have to satisfy.
* **UIManagerBinding is a HostObject**
Practically that means:
1. It must be constructed "on JavaScript thread" (with exclusive access to JavaScript VM);
2. It must not be retained by other parts of the system because overliving the VM will cause a crash.
3. It can be destructed on any thread (VM does not give any guarantees here). The particular configuration guarantees that the destruction cannot be run concurrently with any JS execution though (because we never clear the reference to the host object from JavaScript side).
* **UIManager needs to be connected with UIManagerBinding and vice-versa**
Those to modules call each other to perform some UI updates or deliver events.
* **Scheduler can be deallocated on any thread at any time**
Timing and thread are up to the application side. The Scheduler must be resilient to that.
* **EventDispatcher can call UIManager at any time**
Luckily, that happens only on JavaScript thread.
* **Using weak pointers cames at a cost**
`std::weak_ptr` is a concept for managing the non-owning relationships in a safe manner. Dereferencing such pointers cames at a cost (additional object construction and atomic counters bumps). So, we should use that carefully; we cannot use shared and week pointers everywhere and assume that will work magically.
# How does this blow up?
Without describing the current configuration, here are a variety of cases that we currently observe.
1. `Scheduler` was deallocated and destroyed UIManager but VM is still running. The VM calls the UIManagerBinding, UIManagerBinding calls a method on already deallocated UIManager. Boom.
2. VM is being deallocated and deletes all host object as part of this process. Some UI event is sill in flight on some thread. The event retains UIManagerBinding via UIManager. VM cannot destroy UIManagerBinding because it's being retained. Boom.
3. VM was deallocated. `Scheduler` was deallocated. But some native state update is still in flight. It retains EventDispatcher and eventually trying to access some shadow tree that was retained by Scheduler and already dead. Boom.
That's pretty much routine endless nightmare of any low-level framework. Luckily, the good proper decisions (and iterating on that!) can solve that.
# Proposed configuration
The configuration is based on those ideas:
1. Never retain `UIManagerBinging`.
2. Never recreate `UIManagerBinging`. Create once and load lazily from JS environment on demand.
3. Consider UIManager as an object with shared ownership between JS and native. That object must be able to overlive native infra or JS VM.
4. Use EventDispatcher as a single weak representation of the JavaScript world; Never retain it strongly except by the Scheduler.
5. `UIManagerBinging` and `UIManager` can be attached or detached. `UIManagerBinging` retains `UIManager`, `UIManager` does not retain `UIManagerBinging` back. Destroying `UIManagerBinging` nulls the raw pointer to that from `UIManager`.
6. All calls from native to JavaScript can validate the pointer from `UIManager` to `UIManagerBinging` to check that the call is possible. All that calls happen on JavaScript thread.
## Stages
* **Creation process**
Creation Scheduler creates `UIManager` and scheduler asynchronous call to JavaScript to create `UIManagerBinding` and attach them. At the same time `Scheduler` creates `EventDispatcher` and makes it retains `UIManager`.
* **JavaScript-to-native invocation**
`UIManagerBinding` has a shared pointer to `UIManager` and can cheaply and safely verify that the pointer is not nullptr. Any mutation of this pointer happens on the JavaScript thread or effectively on VM destruction (non-concurrently).
* **Native-to-JavaScript invocation**
The invocation starts from retaining `EventDispatcher` (converting a weak pointer to strong one), that retains `UIManager`. Later, on the JavaScript thread, `UIManager` checks the raw pointer to `UIManagerBinding` to verify that the call can be performed safely.
# Easy ways to break the fragile balance
- Never retain `EventDispatcher` as a shared pointer. That causes a leak of UIManager and associated resources.
- Access a shared pointer to `UIManager` by value only. The simple way to break that is to specify `[=]` capture block for a lambda and access an instance variable pointing to a `UIManager` (that does not retain the pointer; make a copy on the stack and copy that to the lambda).
Reviewed By: JoshuaGross
Differential Revision: D17120333
fbshipit-source-id: 83138657683e91ceb2f48f18f30e745199c83e82
Summary: We don't use it anymore. (And that was debug only concept.)
Reviewed By: sammy-SC
Differential Revision: D17115538
fbshipit-source-id: 20aac5457e37666cbf9ca9f62cdfca411026c219
Summary: We don't use it anymore.
Reviewed By: JoshuaGross
Differential Revision: D17115539
fbshipit-source-id: e1fa5cc023cd27e53307aa0ea8eae0bad5413be3
Summary: Storing a strong shared pointer to `ComponentDescriptor` can cause a memory leak. Therefore we enforce all call sides and params to be weak pointers. The only Scheduler preserves a retaining pointer to it (to prevent preliminary deallocation).
Reviewed By: sammy-SC
Differential Revision: D17115540
fbshipit-source-id: fdea7d19f742ff04d5ba5470dd9748a5b226aa7c
Summary: Yoga is currently published in cocoapods. While we don't use the Yoga from Cocoapods in React Native, we should atleast try to follow that version, so that other integrations with Yoga are possible
Reviewed By: shergin
Differential Revision: D17127625
fbshipit-source-id: bca2e1e33ad775e2a0d7a6f1e4177c3b480c023a
Summary:
Needed to capitalize the name, since this is the convention used elsewhere too
## Changelog:
[iOS] [Changed] - Renamed yoga podspec to Yoga
Reviewed By: shergin
Differential Revision: D17127104
fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
Summary: That was always part of design, that's okay to get a newer state from any other state. We will need it in the future diffs.
Reviewed By: sammy-SC
Differential Revision: D17053429
fbshipit-source-id: 2174e7d6e3a1ed231f7f6e238d216d0b09ec8797
Summary:
It's okay in Fabric model to commit some subtrees which are kinda obsolete (that's strange but technically it's not against the model), but it's not okay to commit some states that were already committed before.
This diff prevents that.
Reviewed By: JoshuaGross
Differential Revision: D17053428
fbshipit-source-id: fb3536312163b7b57011647b4ba7b931c2179d89
Summary: This diff adds support from `ScrollView::scrollEventThrottle` property on iOS.
Reviewed By: JoshuaGross
Differential Revision: D17000397
fbshipit-source-id: 93f23919a6a2588000c0eeca869171d1036348b6
Valentin Shergin
Ramanpreet Nara
Samuel Susla
Gabriel Furini
REDMOND\acoates
Kevin Gozali
Riley Dulin
Daniel Andersson
Janic Duplessis
Hassan Bazzi
zhongwuzw
Anandraj
Jakob Krigovsky
Rick Hanlon
Kudo Chien
Joshua Gross
--fbcode@fb.com
Ram N
glevi@fb.com
