Summary:
Trivial.
If you have troubles with rebasing on top of this revision, run this on your diff:
$ find */*.h */*.mm */*.cpp */*.m -exec clang-format -style=file -i {} \;
Reviewed By: JoshuaGross
Differential Revision: D14018903
fbshipit-source-id: fd0ce2da0e11954e683385402738c701045e727c
Summary:
There is no reason to allocate views ahead of time on the main thread.
There is a chance that this view will not be mounted and we are not saving any time because it's a sequential process anyway (because we are doing it on the main thread). Moreover, the switching context can only slowdown JS execution.
Reviewed By: JoshuaGross
Differential Revision: D14019433
fbshipit-source-id: 83ac05a91e4b70cb382a55d6687752480984404e
Summary: Recycling and dealloc were not implemented at all before for Slider, so I've taken a first stab at it. It's a little more complex than I initially thought, due to things I don't 100% understand about UISlider as well as Fabric, so I've left a TODO note to fix this at some point. We should be aware that view recycling doesn't appear to be working the way I would expect currently though.
Reviewed By: shergin
Differential Revision: D13965475
fbshipit-source-id: fd18a219cead770b63b514fdc868e23214e735b7
Summary: Don't use shared_ptr in this case, it's not needed.
Reviewed By: shergin
Differential Revision: D13965413
fbshipit-source-id: ec98c13f53c7d558a0cb68cea0f97568dd202cd8
Summary: The biggest change is that (1) the image proxy/observer code from the Image component has been generalized, (2) the four image props for the Slider component are fully supported, (3) a handful of props that were ignored or buggy on iOS now perform as expected.
Reviewed By: shergin
Differential Revision: D13954892
fbshipit-source-id: bec8ad3407c39a1cb186d9541a73b509dccc92ce
Summary:
This diff adds performance loggers for Fabric in Android to be able to compare current version or RN with Fabric
This is the summary of Points and Annotations:
- **UIManager_CommitStart**: time that React starts the commit (react tree is ready to start rendering in native)
- **UIManager_LayoutTime**: this is the time it takes to calculate layout in yoga
- **UIManager_FabricFinishTransactionTime**: Time it takes transform "C++ mutationInstructions" into "Java MountItems" and cross boundaries from C++ to Java (including serialization of data) (THIS IS ONLY FABRIC)
- **UIManager_DispatchViewUpdates**: time right before RN moves the mount operations to the Queue that is going to be processed in the next tick UI thread
- **UIManager_BatchRunStart**: time right before the mountItems are going to be process in the UI Thread
- **UIManager_BatchedExecutionTime**: time it took to run batched mountItems (usually layout and prop updates on views)
- **UIManager_NonBatchedExecutionTime**: time it took to run non-batched mountItems (usually creation of views)
Reviewed By: fkgozali
Differential Revision: D13838337
fbshipit-source-id: 0a707619829e7d95ce94d9305ff434d1224afc46
Summary: Folly promises/futures have been replaced by an observer model which keeps track of loading state. This resolves at least one crash that I can no longer repro and simplifies the code a bit (IMO).
Reviewed By: shergin
Differential Revision: D13743393
fbshipit-source-id: 2b650841525db98b2f67add85f2097f24259c6cf
Summary: Objective-C side of the Fabric-compatible slider component for iOS.
Reviewed By: mdvacca
Differential Revision: D13745263
fbshipit-source-id: 647631d6fc86f81a5d4f735c507636ed9c468093
Summary: This diff open sources Fabric Android implementation and it extracts ComponentDescriptorFactory into a function that can be "injected" per application
Reviewed By: shergin
Differential Revision: D13616172
fbshipit-source-id: 7b7a6461216740b5a1ad5ebbead9e37de4570221
Summary: We are now generating the native cpp files for Switch via Buck. Deleting the hand written files and switching over.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13666672
fbshipit-source-id: 72cf6f6af9374511f2742f8f0d996fa52e1bff5b
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:
`RCTSurfaceHostingProxyRootView` surfaces are still automatically started right after the initialization to match `RCTRootView` interface, but `RCTSurfaceHostingView` must be started explicitly now. Also fixed some internal stuff so start and register are clear and distinct.
Background / initial motivation:
One tricky bit - we render the template as part of init`ing the rootView, so we don't know what the surfaceId will be before hand to register the UITemplate. Two possible solutions:
1) Require start be called explicitly after initializing the rootView, and setup the context in between.
2) Do something like "setUITemplateConfigForNextSurface" before creating the rootView, and have some hook when the surfaceId is assigned that associates the surfaceId with that "next" UITemplate stuff before.
(1) seems a lot cleaner, but it requires ever user of rootView to explicitly call start on it - how do you feel about that? Seems like we could also use that start call to decide if the initial render should be synchronous or not? start vs. startSync?
Reviewed By: mdvacca
Differential Revision: D13372914
fbshipit-source-id: 6db297870610e6c231f8a78c0dd74d584cb64910
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:
So, it does not start itself automatically right after instantiation.
(Classic RCTSurface still kinda start itself automatically but only because start/stop concept is not implemented for this yet.)
Reviewed By: sahrens
Differential Revision: D13461294
fbshipit-source-id: 05430688f69a0d9bf75d03e6d25f02ccd5d3176a
Summary: Each app may provide different impl for its runtime specific behaviors, then Fabric and other new infra can share the same config instance to configure stuffs.
Reviewed By: sahrens
Differential Revision: D13290319
fbshipit-source-id: 30e3eeedc6ff6ef250ed233b27e38cb7c1062b55
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:
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: Over-retaining a LocalData object inside the View can cause a crash during tearing down JS VM because LocalData can indirectly retain EventEmitter objects which were not properly "disabled".
Reviewed By: sahrens
Differential Revision: D13196887
fbshipit-source-id: 001d9fadf775c89f750c84fe8da9b84d4636631c
Summary: RCTViewComponentView retains an EventEmitter, so we have to clear this up after we recyled the view.
Reviewed By: sahrens
Differential Revision: D13196884
fbshipit-source-id: e9f2e2400be864c5c6177227255012101ed8c4d1
Summary: View recycling can be pretty aggressive and memory intensive, so we can properly react on system memory-pressure notification.
Reviewed By: mdvacca
Differential Revision: D13176278
fbshipit-source-id: 38ea1b27da988aeaaa5db6ac0b94389a0bd2799e
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:
The whole mounting iOS infra now uses `ComponentHandle` instead of `std::string` as a reference to particular `ComponentView` implementation. All changes are pretty straightforward, we use a different thing/type to refer to the particular class; no changes in the logic besides a new `RCTComponentViewFactory` that serves the same role of classes registry as Objective-C runtime served previously.
That has several benefits:
* It should be slightly faster, mostly because we don't need to convert `char *` strings to `std::string` and then to `NSString *`.
* We don't need string-based component-name maps anymore (at least on this layer). We can call classes as we want and it will work because of classes are now explicit about which ShadowNodes they are compatible with.
* Most importantly, it's explicit now! That means that no runtime magic is involved anymore and we can rely on static linting tool now and not be afraid of improper code stripping/overoptimization.
Reviewed By: mdvacca
Differential Revision: D13130760
fbshipit-source-id: aadf70525a1335b96992443abae4da359efdc829
Summary: The new method in the protocol enforces view component classes to expose a component handle of the component that the view component represents. That will allow us to wire up those classes with shadow views in runtime explicitly and in a much more performant way than it is now.
Reviewed By: mdvacca
Differential Revision: D13114663
fbshipit-source-id: 853187d978aab200f85719d9c1d9fea2e3ad4e55
Summary: Future::then taking a value-taking function is deprecated and being deleted. This cleans up a few more callsites.
Reviewed By: yfeldblum, shergin
Differential Revision: D13163277
fbshipit-source-id: 98d1f78c5b34ca34603cc24d79157a4718573576
Summary: That's a temporary change that useful only while we don't have deeper/proper intergration with UIKit's navigation infra.
Reviewed By: mdvacca
Differential Revision: D13104172
fbshipit-source-id: 024e71e04470d56d2c5e9b3f6c3392555ce50b63
Summary:
Apparently, if a gesture recognizer got 'reset', OS does not call `touchesCancelled:` method, so we have to do it manually.
To implement this we have to split `_dispatchTouches:eventType:` into two methods: the first converts Objective-C touches to C++ touches, the second consumes that. We have to do this because during reset we don't have a collection of UIKit touches.
Reviewed By: mdvacca
Differential Revision: D13072807
fbshipit-source-id: 677e2febf9f96dcdfaadfadf5b9ab3893f93e796
Summary: Every C++ engineer (except me several months ago) knows that `operator []` can mutate the collection (Yeah! Don't ask), so this is especially dangerous if your hash function is broken (see the previous diff).
Reviewed By: mdvacca
Differential Revision: D13072805
fbshipit-source-id: 4436a8ff12fb27a57bfb6ee0ff986d7a9a825549
Summary:
Without this fix the PointerHasher hashed not a pointer, but an address where the pointer is stored, which is obviously incorrect.
The incorrect hash function compromised the whole `_activeTouches` caused many issues with logically invalid invariants (e.g. removing element from the collection silently didn't work).
Reviewed By: mdvacca
Differential Revision: D13072804
fbshipit-source-id: d68289e940fe21e2df08a31439619b7e2fe0fa13
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: 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: Trivial. We don't use it anymore.
Reviewed By: mdvacca
Differential Revision: D12876743
fbshipit-source-id: dc979aaea1fef443b8caf2e58d44b0c7aad90246
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: Now we use RuntimeExecutor instead of MessageQueue; that's more clear and remove a dependency from Bridge.
Reviewed By: sahrens
Differential Revision: D12837226
fbshipit-source-id: 0ea3782ce2f49c7f3a91425880863e3b3ea37712
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:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary: The code fragment `super.accessibilityLabel` always meant "use stored value which came from Props". But after we override the implementation of this getter in the base class, this starts working differently (wrong). This change basically reverts that to original intent.
Reviewed By: sahrens
Differential Revision: D10350597
fbshipit-source-id: 913951eb08c4ede76fc0e9be76b48d86599bcc62
Summary: Empty string in AccessibilityProps basically means same as `nil` in iOS Accessibility API.
Reviewed By: sahrens
Differential Revision: D10350596
fbshipit-source-id: fad9cdc914388c72e1b8261b27f14cbfa9a037db
Summary: We didn't have support for them... and now we have it.
Reviewed By: sahrens
Differential Revision: D10280430
fbshipit-source-id: 7275d4617ed3994366f673a17c24b823293d7092
Summary:
This diff fixes previously broken custom border rendering.
We need a dedicated CALayer for border bitmap in order to fully support all UIView capabilities in case if some subclass uses that. Otherwise, any call of `drawRect:` method can override any content which is stored inside `contents` property of CALayer.
Q&A:
How does it work in current RN? - It does not. All `drawRect:` methods in RCTView subclasses are dysfunctional.
How does text view work in current RN? - RCTTextView does not inherit RCTView, so it does not have this problem.
How does text view support custom borders in current RN then? - It does not.
Reviewed By: PeteTheHeat
Differential Revision: D10228805
fbshipit-source-id: 22bc31f41ab1914a97f3a5981cd1b24ebca725cd
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
Reviewed By: sahrens
Differential Revision: D10081501
fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
