Summary:
Perf numbers for this stack are given in terms of before-stack and after-stack, but the changes are split up for ease of review, and also to show that this migration CAN happen per-component and is 100% opt-in. Most existing C++ components do not /need/ to change at all.
# Problem Statement
During certain renders (select critical scenarios in specific products), UIManagerBinding::createNode time takes over 50% of JS thread CPU time. This could be higher or lower depending on the specific product and interaction, but overall createNode takes a lot of CPU time. The question is: can we improve this? What is the minimal overhead needed?
The vast, vast majority of time is taken up by prop parsing (specifically, converting JS values across the JSI into concrete values on the C++ props structs). Other methods like appendChild, etc, do not take up a significant amount of time; so we conclude that createNode is special, and the JSI itself, or calling into C++, is not the problem. Props parsing is the perf problem.
Can we improve it? (Spoiler: yes)
# How does props parsing work today?
Today, props parsing works as follows:
1. The ConcreteComponentDescriptor will construct a RawPropsParser (one per component /type/, per application: so one for View, one for Image, one for Text... etc)
2. Once per component type per application, ConcreteComponentDescriptor will call "prepare" on the RawPropsParser with an empty, default-constructed ConcreteProps struct. This ConcreteProps struct will cause RawProps.at(field) for every single field.
3. Based on the RawProps::at calls in part 2, RawPropsParser constructs a Map from props string names (width, height, position, etc) to a position within a "value index" array.
4. The above is what happens before any actual props are parsed; and the RawPropsParser is now ready to parse actual Props.
5. When props are actually being parsed from a JSI dictionary, we now have two phases:
1. The RawPropsParser `preparse`s the RawProps, by iterating over the JSI map and filling in two additional data structures: a linear list of RawValues, and a mapping from the ValueIndex array (`keyIndexToValueIndex_`; see step 3) to a value's position in the values list (`value_` in RawPropsParser/RawProps);
2. The ConcretePropT constructor is called, which is the same as in step 2/3, which calls `fieldValue = rawProps.at("fieldName")` repeatedly.
3. For each `at` call, the RawProps will look up a prop name in the Map constructed in step 3, and either return an empty value, or map the key name to the `keyIndexToValueIndex_` array, which maps to a value in `values_`, which is then returned and further parsed.
So, a few things that become clear with the current architecture:
1. Complexity is a property of the number of /possible/ props that /can/ be parsed, not what is actually used in product code. This violates the "only pay for what you use" principal. If you have `<View opacity={0.5} />`, the ViewProps constructor will request ~170 properties, not 1!
2. There's a lot of pre-parsing which isn't free
3. The levels of indirection aren't free, and make cache misses more likely and pipelining is more challenging
4. The levels of indirection also require more memory - minor, but not free
# How can we improve it?
The goal is to improve props parsing with minimal or zero impact on backwards-compability. We should be able to migrate over components when it's clear there's a performance issue, without requiring everything gets migrated over at once. This both (1) helps us prove out the new architecture, (2) derisks the project, (3) gives us time, internally and externally, to perfect the APIs and gradually migrate everything over before deleting the old infrastructure code entirely.
Thus, the goal is to do something that introduces a zero-cost abstraction. This isn't entirely possible in practice, and in fact this method slightly regresses components that do not use the new architecture /at all/, while dramatically improving migrated components and causing the impact of the /old/ architecture to be minimal.
# Solution
1. We still keep the existing system in place entirely.
2. After Props are constructed (see ConcreteComponentDescriptor changes) we iterate over all the /values/ set from JS, and call PropsT::setProp. Incidentally, this allows us to easily reuse the same prop for multiple values for "free", which was expensive in the old system.
3. It's worth noting that this makes a Props struct "less immutable" than it was before, and essentially now we have a "builder pattern" for Props. (If we really wanted to, we could still require a single constructor for Props, and then actually use an intermediate PropsBuilder to accumulate values - but I don't think this overhead would be worth for the conceptual "immutability" win, and instead a "Construct/Set/Seal" model works fine, and we still have all the same guarantees of immutability after the parsing phase)
# Implementation Details
# How to properly construct a single Prop value
Minor detail: parsing a single prop is a 3-step process. We imagine two scenarios: (1) Creating a new ShadowNode/Props A from nothing/void, so the previous Props value is just the default constructor. (2) Cloning a ShadowNode A->B and therefore Props A must be copied to Props B before parsing.
We will denote this as a clone from A->B, where A may or may not be a previous node or a default-constructed Props node; and imagine in particular that we're setting the "opacity" value for PropsB.
We must first (1) copy a value over from the previous version of the Props struct, so B.opacity = A.opacity; (2) Determine if opacity has been set from JS. If so, and there is a value, B.opacity = parse(JSValue). (3) If JS has passed in a value for the prop, BUT the value is `null`, it means that JS is resetting or deleting the prop, so we must set it BACK to the default. In this case we set PropsB.opacity = DefaultConstructedProps.opacity.
We must take care in general to ensure that the correct behavior is achieved here, which should help to explain some of the code below.
## String comparisons vs hash comparisons
In the previous system, a RawPropsKey is three `const char*` strings, concatenated together repeatedly /at runtime/. In practice, the ONLY reason we have the prefix, name, suffix Key structure is for the templated prop parsing in ViewProps and YogaStyableProps - that's it. It's not used anywhere else. Further, the key {"margin", "Left", "Width"} is identical to the key {"marginLeftWidth", null, null} and we don't do anything fancy with matching prefixes before comparing the whole string, or similar. Before comparison, keys are concatenated into a single string and then we use `strcmp`. The performance of this isn't terrible, but it's nonzero overhead.
I think we can do better and it's sufficient to compare hashed string values; even better, we can construct most of these /at compile time/ using constexpr, and using `switch` statements guarantee no hash collisions within a single Props struct (it's possible there's a collision between Props.cpp and ViewProps.cpp, for example, since they're different switch statements). We may eventually want to be more robust against has collisions; I personally don't find the risk to be too great, hash collisions with these keys are exceedingly unlikely (or maybe I just like to live dangerously). Thus, at runtime, each setProp requires computing a single hash for the value coming from JS, and then int comparisons with a bunch of pre-compiled values.
If we want to be really paranoid, we could be robust to hash collisions by doing `switch COMPILED_HASH("opacity"): if (strcmp(strFromJs, "opacity") == 0)`. I'm happy to do this if there's enough concern.
## Macros
Yuck! I'm using lots of C preprocessor macros. In general I found this way, way easier in reducing code and (essentially) doing codegen for me vs templated code for the switch cases and hashing prop names at compile-time. Maybe there's a better way.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050215
fbshipit-source-id: d2dcd351a93b9715cfeb5197eb0d6f9194ec6eb9
Summary:
A huge set of props use YGValue directly, say something really basic like `margin`/`position`/`padding`/`border`.
All of these according to CSS spec actually support `number | "em" | "px" | %` units, but we are going to throw and hard crash on `em` and `px`, which are unsupported in React Native.
Using `tryTo` instead of `to` (noexcept vs throwing method) for conversion, and treating things like `margin: 50px` same way as we would treat `margin: false` which is not really supported.
Changelog:
[General][Fixed] - Fixed a crash on deserialization of props when using 'px'/'em' units.
Reviewed By: bvanderhoof
Differential Revision: D37163250
fbshipit-source-id: 59cbe65a821052f6c7e9588b6d4a0ac14e344684
Summary:
We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D31057046
fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5
Summary:
TurboCxxModule doesn't use the the default JSI getter that TurboModule offers, and has custom behaviour for `getConstants` which broke the I18nAssets module in the binding experiment.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37030917
fbshipit-source-id: 187f159abc76f792ad2c7045dc2852d216ea978d
Summary:
This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`.
Changelog:
Internal
Reviewed By: javache
Differential Revision: D36989312
fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b
Summary:
This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See https://github.com/facebook/react-native/pull/33381.
The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers.
Tested in the YogaKitSample, and also in a react-native app.
Changelog:
[iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus
X-link: https://github.com/facebook/yoga/pull/1150
Reviewed By: dmitryrykun
Differential Revision: D36966687
Pulled By: cortinico
fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39
Summary:
Seems like an obvious typo! Whoops!
Not causing any known issues, but... this should be fixed.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36940476
fbshipit-source-id: d534ca3763b1f91e41c56953bf3d665e86db9e2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
The current implementation of `throwJSError` places it in jsi.cpp, but
does not actually export it. This means that when JSI is being provided
by a dynamic library, `detail::throwJSError` will not be available.
To fix this, move the definition of `throwJSError` into jsi-inl.h,
similar to all of the other functions in the `detail` namespace. This
uses a roundabout implementation of `throwJSError` in order to avoid
directly using `throw`, which would fail to compile when exceptions are
turned off.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D36873154
fbshipit-source-id: bbea48e0d4d5fd65d67a029ba12e183128b96322
Summary:
See also D36889794. This is a very similar idea, except the core problem is that BaseTextProps is accessing the same props as ViewProps; and for ParagraphProps parsing, it first defers to ViewProps' parser and then BaseTextProps. RawPropsParser is optimized to access the same props in the same order, *exactly once*, so if we access a prop out-of-order, or for a second time, that access and the next access are deoptimized. Paragraph/Text, in particular, were quite bad because we did this several times, and each out-of-order access requires scanning /all/ props.
This fixes the issue, at least partially, by (1) pulling all the duplicate accesses to the beginning of BaseTextProps, and (2) accessing them all in the same order as ViewProps, relatively (some props are skipped, but that matters less).
Practically what this means is that now, all of Props' accesses have a cost of O(1) for lookup, or a total of O(n) for all of them; each access is at the n+1 position in the internal RawPropsParser array, so each access is cheap. BaseTextProps' duplicate accesses, even though there are only 4 of them: (1) the first one scans the entire array until we reach the prop in question; (2) the next accesses require scans, but not whole-array scans, since they're in order. (3) The BaseTextProps accesses /after/ the duplicate accesses are all O(1).
tl;dr is that before we had something like O(n*6) cost for BaseTextProps parsing and now it is O(n*2).
Similar to my summary in the last diff: we may want to revisit the RawPropsParser API... but I want to tread gently there, and this gets us a large improvement without major, risky changes.
Empirically, based on a couple of systraces, average time for a single UIManager::createNode called from JS thread, before this stack: 17us. After: 667ns (3% as long). On average, for every 60 createNode calls, we will save 1ms on the UI thread. The savings will be greater for certain screens that use many Views or Text nodes, and lesser for screens that use fewer of these components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36890072
fbshipit-source-id: 5d24b986c391d7bb158ed2f43d130a71960837d1
Summary:
Without getting into the weeds too much, RawPropParser "requires" that props be accessed in the same order every time a Props struct is parsed in order to most optimally fetch the values in a linear-ish fashion, basically ensuring that each rawProps.at() call is an O(1) operation, and overall getting all props for a particular component is O(n) in the number of props for a given struct. If props are called out of order, this breaks and worst-case we can end up with an O(n^2) operation.
Unfortunately, calling .at(x) twice with the same prop name triggers the deoptimized behavior. So as much as possible, always fetch exactly once and in the same order every time. In this case, we move initialization of two fields into the constructor body so that we can call .at() a single time instead of twice.
In the debug props of ViewProps I'm also reordering the fields to fetch them in the same order the constructor fetches them in, which will make this (debug-only) method slightly faster.
What's the impact of this? If you dig into the Tracery samples, the average/median RawPropsParser::at takes 1us or less. However, in /every single/ call to createNode for View components, there is at least one RawPropsParser::at call that takes 250+us. This was a huge red flag when analyzing traces, after which it was trivial (for View) to find the offending out-of-order calls. Since this is happening for every View and every type of component that derives from View, that's 1ms lost per every 4 View-type ShadowNodes created by ReactJS. After just 100 views created, that's 25ms. Etc.
There are other out-of-order calls lurking in the codebase that can be addressed separately. Impact scales with the size of the screen, the number of Views they render, etc.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36889794
fbshipit-source-id: 91e0a7ca39ed10778e60a0f0339a4b4dc8b14436
Summary:
This target is not a good idea for a number of reasons:
1. It groups up multiple targets which breaks the dependency graph
2. It does not handle dependency remapping correctly
3. It has no mirror into fbcode
We should warn people this is a bad idea
Reviewed By: alexmalyshev
Differential Revision: D36519357
fbshipit-source-id: d60ca3237c7710118732578fecd1b2fc8903321b
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.
1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)
Changelog: [Internal]
Reviewed By: JoshuaGross, rubennorte, mdvacca
Differential Revision: D36590018
fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36592492
fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
Codegen a static field for every caller of `invokeJavaMethod` to cache the jmethodID that should be used for the method, which saves us a string-based name lookup at invocation time.
Changelog: [internal]
Reviewed By: genkikondo
Differential Revision: D36376056
fbshipit-source-id: 298430746a8f25a5337aba05b56876ba789e2344
Summary:
Simplify argument and result conversion by using existing fbjni helpers (which will cache class and method ID lookups already)
Changelog: [internal]
Reviewed By: RSNara
Differential Revision: D36312751
fbshipit-source-id: 16713642b2c5fb4c2b6447c30652d91ddbd88224
Summary:
Noticed that we emit a large amount of (admittedly cheap) mountitems as part of node creation for values that are all zero (e.g. padding, overflowinset), which we can assume to be already initialised with these values on the native side.
There's a further opportunity to do this for State as well, as ReactImageComponentState exports just empty maps to Java.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36345402
fbshipit-source-id: 8d776ca124bdb9e1cd4de57a04e2785a9a0f918c
Summary: Changelog: [iOS][Internal] - Only fire pointerEnter/Leave events if a view in the event path is listening to that event
Reviewed By: yungsters
Differential Revision: D35911045
fbshipit-source-id: 8b3021619622c3e83c15acea46c23bfe3e0f9284
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Ideally, the application should always be able to create the TurboModule object given an ObjC class. This debugging information will help track down these classes of issues, when they surface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D35945399
fbshipit-source-id: 1621a4a64bc8fb0411123fb1470bbb52ccf0edcf
Summary:
During the TurboModule init path, the TurboModuleManager asks the application to create the TurboModule object, given its class.
If the application is unable to create the TurboModule object, what should we do?
0. **What we do now:** Continue executing TurboModule init path.
1. Silently return nil early.
2. Silently return nil early, and RCTLogError.
If we Continue executing the TurobModule init path, we'll run into a segfault, because we'll call objc_setAssociatedObject(nil, ...).
This diff prevents that segfault, by doing a silent return of nil.
Changelog: [iOS][Fixed] - Prevent Nullptr segfault in TurboModule init path
Reviewed By: fkgozali
Differential Revision: D35942323
fbshipit-source-id: 7755800379c4bc733502314f3af3f401e9b04872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33688
These methods used to be public in the legacy implementation, and hiding them significantly reduces amount of customization available to other clients outside Fabric core.
Changelog: [Internal] Allow external callers to call UIManager methods
Reviewed By: cipolleschi
Differential Revision: D35818114
fbshipit-source-id: 4dc4177c82b5db9ae3d136a1a83f5ec3123b971f
Summary:
Minimal set of changes to intercept events in external modules. Current intended use-case is for Reanimated to handle events for the Animated properties.
Changelog: [Added] Add listeners to allow intercepting events in C++ core.
Reviewed By: cipolleschi
Differential Revision: D35312534
fbshipit-source-id: ec924b57fd0c0dabf7be7b886dbef23bf3170d6c
Summary:
Ensures that transaction telemetry modified by transaction controller is the same as sent in the view callbacks.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D35827347
fbshipit-source-id: 123ae01d4a7fe1a9c97ebccae3ae248f7f2cf654
Summary:
https://fb.workplace.com/groups/fbapp.commerce.engsupport/permalink/2074812256012212/
Back out "[react-native][PR] Pass mutation list to RCTMountingTransactionObserving callbacks"
Original commit changeset: f40afc512f2c
Original Phabricator Diff: D35214478 (91fc2c0091)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D35825832
fbshipit-source-id: b53b616dca39c84b3a8e8e4cbaa4a45834e53fe3
Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.
This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.
One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.
Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.
In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.
## Changelog
[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects
Pull Request resolved: https://github.com/facebook/react-native/pull/33510
Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)
Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.
Reviewed By: cipolleschi
Differential Revision: D35214478
Pulled By: ShikaSD
fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
Summary:
During the sheriff shift, incorrectly reverted a diff. fixing it by reverting the revert.
Original commit changeset: b5a6c9f6f576
Original Phabricator Diff: D35705825 (a7a0f86a73)
See : https://fb.workplace.com/groups/mobile.sheriffs/posts/8461935673854973/?comment_id=8462686143779926
The current JSI implementation is converting a Symbol to String when creating a jsi Value.
Changelog: [General][Fixed]
Reviewed By: neildhar
Differential Revision: D35710710
fbshipit-source-id: d36667001002032a37569c9bc5288d10b9bc7011
Summary:
The current JSI implementation is converting a Symbol to String when creating a jsi Value.
Changelog: [General][Fixed]
Reviewed By: neildhar
Differential Revision: D35705825
fbshipit-source-id: 3bee0a02bb77643c6a33031b4d98ac9a7e126303
Summary:
Problem:
Current creation of ModuleConfig does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Fix:
Use std::move semantics to avoid copy of folly::dynamic, thus avoiding memory allocations.
## Changelog
[General] [Fixed] - Avoid full copy of large folly::dynamic objects by switching to std::move semantics
Pull Request resolved: https://github.com/facebook/react-native/pull/33621
Test Plan:
Compiled React Native for Windows
Consumed into Microsoft Excel App
Tested functionality through Microsoft Office Excel App
Viewed Memory Allocations in Debugger
Reviewed By: cortinico
Differential Revision: D35599759
Pulled By: RSNara
fbshipit-source-id: 095a961422cca4655590d2283f6955472f1f0410
Summary:
I guess it's the same since we're working on a `bool` but... this causes some compilation error.
Changelog:
[General][iOS] - Fix compilation warning in yoga
Reviewed By: Andrey-Mishanin
Differential Revision: D35438992
fbshipit-source-id: 22bb848dfee435ede66af0a740605d4618585e18
Summary:
The `override` keyword was used for some overriden methods and was not
used for others. This caused the `-Winconsistent-missing-destructor-override`
warning to show up, and since in some cases we build with `-Werror`, this broke
the build.
This diff adds the missing `override` keyword in a few places.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: kodafb
Differential Revision: D35513149
fbshipit-source-id: 92bca699f1be163189487d50c1050402df2ff038
Summary:
there are build errors happened when in [`generate_multiple_pod_projects`](https://blog.cocoapods.org/CocoaPods-1.7.0-beta/#multiple-xcodeproj-generation) mode and fabric is on. since we have multiple pod projects, there are something breaks.
### `-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm`
because `installer.pods_project` is targeting `Pods.xcodeproj` but not `React-Core.xcodeproj`. we should use ` installer.target_installation_results.pod_target_installation_results` to deal with `generate_multiple_pod_projects` mode.
### fatal error: 'CompactValue.h' file not found
```
In file included from /path/to/react-native/packages/rn-tester/build/generated/ios/react/renderer/components/rncore/Props.cpp:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Codegen/react/renderer/components/rncore/Props.h:13:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/ViewProps.h:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/YogaStylableProps.h:10:
/path/to/react-native/packages/rn-tester/Pods/Headers/Public/Yoga/yoga/YGStyle.h:16:10: fatal error: 'CompactValue.h' file not found
#include "CompactValue.h"
^~~~~~~~~~~~~~~~
1 error generated.
```
`Props.cpp` -> `YogaStylableProps.h` -> `YGStyle.h` -> `CompactValue.h`
[`CompactValue.h` is internal private header for Yoga pod](4eef075a58/ReactCommon/yoga/Yoga.podspec (L54-L56)) where `React-Codegen` project cannot access to.
~there are some solutions toward this problem. one way is to make other yoga headers as public headers. i am not sure whether this solution would introduce any side effects. so i only make necessary projects to search yoga private headers.~
Update: a solution is to expose all yoga headers publicly. however, CocoaPods will put all public headers to module umbrella header. this will break YogaKit (swift) integration because swift module doesn't support c++. my pr is trying to expose all yoga headers to `$PODS_ROOT/Headers/Public/Yoga/yoga`, but use custom `module_map` to control which headers should be exposed to the swift module. CocoaPods's custom module_map has some limitation where cannot well support for both `use_frameworks!` mode and non use_frameworks! mode. there's a workaround to use `script_phase` copying the umbrella header to right place.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `generate_multiple_pod_projects=true` and Fabric is on
Pull Request resolved: https://github.com/facebook/react-native/pull/33381
Test Plan:
verify with rn-tester
1. add `generate_multiple_pod_projects`
```diff
--- a/packages/rn-tester/Podfile
+++ b/packages/rn-tester/Podfile
@@ -5,7 +5,7 @@ platform :ios, '11.0'
# Temporary solution to suppress duplicated GUID error.
# Can be removed once we move to generate files outside pod install.
-install! 'cocoapods', :deterministic_uuids => false
+install! 'cocoapods', :generate_multiple_pod_projects => true, :deterministic_uuids => false
USE_FRAMEWORKS = ENV['USE_FRAMEWORKS'] == '1'
```
2. pod install and build rn-tester from xcode
Reviewed By: cortinico
Differential Revision: D34844041
Pulled By: dmitryrykun
fbshipit-source-id: 93311b56d8e44491307a911ad58442f267c979eb
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
Update C++ TurboModule codegen to wrap nullable types in `std::optional` whereas before the conversion would cause a crash.
Changelog:
Internal
Reviewed By: mdvacca, nlutsenko
Differential Revision: D35299708
fbshipit-source-id: 7daa50fe8b16879c5b3a55a633aa3f724dc5be30
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
These `constexpr` template variables make it really easy to test for bridging conversion to/from the specified types. The unit tests for this actually uncovered a bug with incompatible casts from lvalue references that was fixed in this diff as well.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D35105398
fbshipit-source-id: 6e5f16e44ba99b296284970bf32c1f2f47201391
Summary:
Adding more context for event dispatching process in systrace.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D35208257
fbshipit-source-id: 4a70e15a0074d4a53a895066e6fa1e60a6ebda0d
Summary:
This PR fixes RTTI (run-time type information) for ShadowNodeWrapper and ShadowNodeListWrapper classes, i.e., calls to dynamic_cast and dynamic_pointer_cast that are called via JSI's getHostObject calls.
The fix is simply to add a so-called "key function" in a form of virtual destructor. Key functions needs to be a virtual non-pure and non-inlined functions that points the compiler as to which library contains the vtable/type information for a given class (see https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable and https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries)
Without the "key function", calls to dynamic_cast for ShadowNodeWrapper instances won't work across library boundaries because the class will have separate definitions in each separate library, therefore objects created in one of those libraries won't be recognized as the same type by the other library. This has been a problem in reanimated and gesture-handler libraries where we call `object.getHostObject<ShadowNodeWrapper>(rt)` (this is a method from JSI) in order to access ShadowNode instance from a handle we have in JS. I think, this issue is going to be relevant to more libraries that cope with view instances. In this scenario, we have a separate library, say "libreanimated.so" that calls to `getHostObject` which is an inline function that calls `dynamic_cast` for the `ShadowNodeWrapper` class. On the other hand, the instances of `ShadowNodeWrapper` are created by the code from `libreact_render_uimanager.so`. Because of that `dynamic_cast` fails even though it is called on instance of `ShadowNodeWrapper` because the class has separate vtable/type info: one in `libreanimated.so` and one in `libreact_render_uimanager.so` (by "fails" I mean that it actually returns `nullptr`).
This problem has been documented here: https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries where the solution is for the class to have a so-called "key function". The key function makes it so that compiler sees that one of the implementation for a given class is missing and therefore can safely assume that a vtable/type info for a given class is embedded into some library we link to.
This change adds a virtual destructor that is declared in the header file but defined in file that gets compiled as a part of `libreact_render_uimanager`. As a result, the compiler only creates one vtable/type info and calls to dynamic_cast works as expected in all libraries for `ShadowNodeWrapper` and `ShadowNodeListWrapper` classes.
This issue would only surface on Android, because on iOS all libraries by default are bundled together via Pods, whereas on Android each library is loaded separately using dynamic loading.
## Changelog
[Fabric][Android specific] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper and similar classes when accessed by third-party libraries.
Pull Request resolved: https://github.com/facebook/react-native/pull/33500
Test Plan:
1. In order to test this you need to add a library that'd include `<react/renderer/uimanager/primitives.h>` (i.e. use this branch of reanimated library: https://github.com/software-mansion/react-native-reanimated/tree/fabric)
2. After compiling the app inspect libreact_render_uimanager.so and libreanimated.so artifacts with `nm` tool
3. Notice that symbols like `vtable for facebook::react::ShadowNodeWrapper` and `typeinfo for facebook::react::ShadowNodeWrapper` are only present in the former and not in the latter library (before this change you'd see them both)
Reviewed By: ShikaSD
Differential Revision: D35143600
Pulled By: javache
fbshipit-source-id: 5fb25a02365b99a515edc81e5485a77017c56eb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33472
Changes native build of ReactAndroid to CMake instead of ndk-build. Removes a few workarounds around AGP issues with ndk-build which seems to be working with CMake by default.
Changelog: [Changed][Android] - Use CMake to build ReactAndroid module
Reviewed By: cortinico
Differential Revision: D35018803
fbshipit-source-id: af477937ed70a5ddfafef4e6260a397ee9911580
Summary:
Aligns two codepaths for measure, making sure we can use both MapBuffer and ReadableMap for measuring components.
Changelog: [Internal] - Align measure interface for MapBuffer experiment
Reviewed By: javache, mdvacca
Differential Revision: D34960317
fbshipit-source-id: a39eb84a0abb4414717463f2f1741e470be3531f
Summary:
Changes in 7cece3423...189c2c895 broke build for Windows because of a conversion from size_t to int. Adds a static cast to int to fix the error and restore windows build
Error Message
```
##[error]node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): Error C2220: the following warning is treated as an error
3>D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): error C2220: the following warning is treated as an error [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
##[warning]node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): **Warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data**
3>D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\core\RawPropsParser.cpp(100,42): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
```
## Changelog
[General] [Fixed] - Restore Windows build with RawPropsParser.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/33432
Test Plan: Tested locally and changes pass in the react-native-windows pipeline, change is being merged into the main branch of react-native-windows.
Reviewed By: philIip
Differential Revision: D34907928
Pulled By: javache
fbshipit-source-id: 8b76cbef0b637f2d607a8aefd2998322c3245713
Summary:
Adds CMake files to configure hermes-executor build, with the same setup as we have in Android.mk
Changelog: [Internal] - CMake build config for hermes executor
Reviewed By: cortinico
Differential Revision: D34811909
fbshipit-source-id: 2df6dbaf46131db87a25e26c83b38ba44f29d1d3
Summary:
This Diff re-applies some of the changes that landed on main
to the CMake files we currently landed so far.
Changelog:
[Internal] [Changed] - Re-apply main changes to CMake files
Reviewed By: ShikaSD
Differential Revision: D34859685
fbshipit-source-id: 772a3aed05f56b6fbb2942bf9d1a5bd4581b48d5
Summary:
We were opening the file multiple times just to read the same couple of bytes.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D34835972
fbshipit-source-id: 9de899f37a9193db4ab72e69e02e8d41e5515da0
Summary:
This Diff moves from specifying a list of files to use file(GLOB) with
CONFIGURE_DEPENDS on several CMakefiles.
I've updates those where we use globbing also inside buck.
Changelog:
[Internal] [Changed] - Setup Globbing with CONFIGURE_DEPENDS inside CMake files
Reviewed By: ShikaSD
Differential Revision: D34826311
fbshipit-source-id: 8fc654626c897cdc4cdd79c699ce19f1e5e1212f
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
`MapBuffer` is not used in RN utils for anything shared for now, so we can remove it from the build config by reordering methods, shaving 20KB in APK size for each architecture.
Also applies clang-tidy rules to `MapBuffer`/`folly::dynamic` configurations.
Changelog: [Internal] - Remove `mapbuffer` dependency from `Android.mk` of reactutilsjni
Reviewed By: javache, cortinico
Differential Revision: D34620455
fbshipit-source-id: ad3717448f5c20fd071f71d436bb9dd00efe7eb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33396
This commit fully unplugs the `ReactAndroid` from using hermes from the NPM package and plugs the usage of Hermes via the `packages/hermes-engine` Gradle build.
I've used prefab to share the .so between the two builds, so we don't need any extra machinery to make this possible.
Moreover, I've added a `buildHermesFromSource` property, which defaults to false when RN is imported, but is set to true when RN is opened for local development. This should allow us to distribute the `react-native` NPM package and users could potentially toggle which source to use (but see below).
Changelog:
[Android] [Changed] - Build Hermes from Source
Reviewed By: hramos
Differential Revision: D34389875
fbshipit-source-id: 107cbe3686daf7607a1f0f75202f24cd80ce64bb
Summary:
This adds the *option* for C++ TurboModules to use a `*CxxSpec<T>` base class that extends the existing (and unchanged) corresponding `*CxxSpecJSI` base class with code-generated methods that use `bridging::calFromJs` to safely convert types between JSI and C++. If a type conversion cannot be made, then it will fail to compile.
Changelog:
[General][Added] - Automatic type conversions for C++ TurboModules
Reviewed By: christophpurrer
Differential Revision: D34780512
fbshipit-source-id: 58b34533c40652db8e3aea43804ceb73bcbe97a5
Summary:
This adds `bridging::callFromJs` that can call class instance methods with JSI arguments and will automagically convert types to the types expected by the method, or otherwise will fail to compile. The same type conversion back to JSI applies as well for the return value, if there is one.
This will allow C++ TurboModules to more easily define their interface in terms of C++ types instead of having to interact with JSI directly for everything, though it remains possibles for JSI values to pass through if that's what a given method wants.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34780511
fbshipit-source-id: 1f9caadeefa6d4023f679e95f3decc64d156b3f0
Summary:
This adds `bridging::toJs` and `bridging::fromJs` functions that will safely cast to and from JSI values and C++ types. This is extensible by specializing `Bridging<T>` with `toJs` and/or `fromJs` static methods. There are specializations for most common C++ and JSI types along with tests for those.
C++ functions and lambdas will effortlessly bridge into JS, and bridging JS functions back into C++ require you to choose `SyncCallback<R(Args...)>` or `AsyncCallback<Args...>` types. The sync version allows for having a return value and is strictly not movable to prevent accidentally moving onto another thread. The async version will move its args onto the JS thread and safely call the callback there, but hence always has a `void` return value.
For promises, you can construct a `AsyncPromise<T>` that has `resolve` and `reject` methods that can be called from any thread, and will bridge into JS as a regular `Promise`.
Changelog:
[General][Added] - New bridging API for JSI <-> C++
Reviewed By: christophpurrer
Differential Revision: D34607143
fbshipit-source-id: d832ac24cf84b4c1672a7b544d82e324d5fca3ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413
This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34723341
fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
Summary:
This is the first round of CMake files to support the React Native build on Android.
They're supposed to eventually replace the various Android.mk files we have around in the codebase.
So far we're not actively using them. This is the first step towards migrating our
setup to use CMake
Changelog:
[Internal] [Changed] - First Round of CMake files for React Android
Reviewed By: ShikaSD
Differential Revision: D34762524
fbshipit-source-id: 6671e203a2c83b8874cefe796aa55aa987902a3b
Summary:
using namespace in header file is a bad practice due to many reasons as well as discouraged by `-Wheader-hygiene` compiler flag which is default for many apps
https://stackoverflow.com/questions/5849457/using-namespace-in-c-headers
Changelog:
[General][Fixed] - Fixed compilation warning due to `using namespace` being used as part of header
Reviewed By: nlutsenko
Differential Revision: D34788523
fbshipit-source-id: 2a50fbf2ac3371ff5670c600c7f5ad9055060ad2
Summary:
This is only defined on Windows, and thus code that compiles on all platforms
may successfully build on Linux/macOS, but not on Windows, making it
potentially harder to detect and debug. Let's unify all platforms to solve
this.
Changelog: [Internal]
Reviewed By: chadaustin
Differential Revision: D34648154
fbshipit-source-id: b2549bb3eb120e6207cab8baaafced8b1b18e6a7
Summary:
Fix a few issues with msggen:
1. run_msggen: fully-qualified path to clang-format
1. Updated the license for autogenerated files
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D34114718
fbshipit-source-id: 831d4b20bfdc39cfa1226e2a32dcb445c8086ff3
Summary:
Changelog: [internal]
To avoid unnecessary string copy in event pipeline, use move semantics.
Event pipeline has ownership of event type. Passing it by reference ends up in a copy when `RawEvent` object is constructed. To avoid this, pass string by value through each layer and use move semantics to avoid extra copies.
Reviewed By: javache
Differential Revision: D34392608
fbshipit-source-id: c11d221be345665e165d9edbc360ba5a057e3890
Summary:
Silence some warnings in xcode 13.3 by explicitly defining some copy constructors in JSI and adding a compiler flag in Hermes.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: jpporto
Differential Revision: D34526541
fbshipit-source-id: 7029e3d20b9209007cf7e9f4c935338513ee1dd0
Summary:
Not having this disallows including turbo module and extending in places where RTTI is enabled.
There is no additional includes or implementation changes - it merely allows for things to nicely link with other libraries.
Changelog: [General][Fixed] - Allow including TurboModule.h in mixed rtti/no-rtti environment, even if TurboModule.h/cpp is compiled without RTTI.
Reviewed By: appden
Differential Revision: D34637168
fbshipit-source-id: 2e5d9e546bdc5652f06436fec3b12f1aa9daab05
Summary:
Changelog:
[iOS][Changed] - Removed methodName parameter that was used only for a warning message and moved the warning parameter to be calculated inline.
Reviewed By: fkgozali
Differential Revision: D34551444
fbshipit-source-id: 6ceba425b64df37b0dca7e222072f1836f151d83
Summary:
This diff fixes overflowInset calculation when a shadow node has transform matrix from a transfrom prop in JS. Specifically, this fixed the use case when transform directly used on a view component. When using Animated.View, it will create an invisible wrapper which will behave correctly with existing logic. This diff bring both use cases to work properly.
When a shadow node has transform on it, it will affect the overflowInset values for its parent nodes, but won't affect its own or any of its child nodes overflowInset values. This is obvious for translateX/Y case, but not for scale case. Take a look at the following case:
```
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│Original Layout │ │ Translate AB │ │ Scale AB │
└────────────────┘ └────────────────┘ └────────────────┘
─────▶ ◀───── ─────▶
┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ┐ ┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐ ┌ ─ ─ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐
│ A │ │ A │ │ A │
│ │ │ │ │ │ │ │ ├ ─ ─ ─ ─ ─ ┼ ─ ─┌─────┤─ ─ ─ ─ ─ ┤
─ ─ ─ ─│─ ─ ─┌───┐┼ ─ ─ ─ ─ │ │ ◀─ ─ ─ │ │AB │ ─ ─ ─▶
│ │ │AB ││ │ │ ┌ ─ ─ ┼ ─ ─ ─ ┬──┴┬ ─ ─ ─ ─ ┤ │ │ │ │ │
└─────┤ ├┘ └───────┤AB │ └────┤ │
│ │┌──┴─────────┤ │ │ │ │ │ │ │ │ ┌───┴──────────┤
││ABC │ │┌──┴─────────┐ │ │ABC │
│ │└──┬─────────┤ │ │ │ ││ABC │ │ │ │ │ │ │
┌───ABD───────┴─┐ │ │ │└──┬─────────┘ │ ▼ │ └───┬──────────┘
├─────────────┬─┘ │ │ │ │ ├───ABD───────┴─┐ │ │ │ ├────────────────┴──┐ │ │
─ ─ ─ ─ ─ ─ ─└───┘─ ─ ─ ─ ─ ▼ └─────────────┬─┘ │ ▼ │ ABD │ │
└ ┴ ─ ─ ─ ─ ─ ─ ┴───┴ ─ ─ ─ ─ ┘ ├────────────────┬──┘ │ │
─ ─ ─ ─ ─ ─ ─ ─ ┴─────┴ ─ ─ ─ ─ ─
```
For the translate case, only view A has change on the overflowInset values for `right` and `bottom`. Note that the `left` and `top` are not changed as we union before and after transform is applied.
For the scale case, similar things are happening for view A, and both `left`, `right`, and `bottom` values are increased. However, for View AB or any of its children, they only *appear* to be increased, but that is purely cosmetic as it's caused by transform. The actual values are not changed, which will later be converted during render phase to actual pixels on screen.
In summary, overflowInset is affected from child nodes transform matrix to the current node (bottom up), but not from transform matrix on the current node to child nodes (top down). So the correct way to apply transform is to make it only affect calculating `contentFrame` during layout, which collects child nodes layout information and their transforms. The `contentFrame` is then used to decide the overflowInset values for the parent node. The current transform matrix on parent node is never used as it's not affecting overflowInset for the current node or its child nodes.
This diff reflects the context above with added unit test to cover the scale and translate transform matrix.
Changelog:
[Android/IOS][Fixed] - Fixed how we calculate overflowInset with transform matrix
Reviewed By: sammy-SC
Differential Revision: D34433404
fbshipit-source-id: 0e48e4af4cfd5a6dd32a30e7667686e8ef1a7004
Summary:
TextMeasurement destructor is not necessary, we are deleting it
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34246015
fbshipit-source-id: 6ca4803fafc8b195828d546ba8fb45353257f383
Summary:
TextLayoutManger should be not copyable / not movable
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D34246013
fbshipit-source-id: dc20db2ad9e2709ddca5bef5218356bd2b292c2d
Summary:
Changelog: [iOS][Internal] Use synthesize viewRegistry_DEPRECATED for Keyframes to remove RCTWeakViewHolder
Remove the `RCTWeakViewHolder` hack, since it can be replaced with `viewRegistry_DEPRECATED viewForReactTag`.
Reviewed By: RSNara
Differential Revision: D34468082
fbshipit-source-id: be41ed2df6ee195409724f6069fd99a793dca01a
Summary:
Changelog: [iOS][Internal] 4/5 Attach synthesize ivars to RCTViewManagers using RCTBridgeModuleDecorator in Bridgeless mode
- In RCTInstance, insert RCTBridgeModuleDecorator into RCTInstance into contextContainer
- In LegacyViewManagerInteropComponentDescriptor.mm, unwrap RCTBridgeModuleDecorator from contextContainer
- Then pass RCTBridgeModuleDecorator from LegacyViewManagerInteropComponentDescriptor to RCTLegacyViewManagerInteropCoordinator
- In RCTLegacyViewManagerInteropCoordinator, call `RCTBridgeModuleDecorator attachInteropAPIsToModule` to attach synthesize ivars to all RCTViewManagers.
This does not affect Bridge mode.
Reviewed By: RSNara
Differential Revision: D34439950
fbshipit-source-id: d814c56a52f226e3a2c96fea01efb51afc571721
Summary:
`size_` will always match `keys_.size()` so we don't have to keep track of it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34391445
fbshipit-source-id: f6c9316c989137425abfb7b3d72b571d08240f34
Summary:
With the `MapBuffer`-based props calculated from C++ props, there's no need to keep `rawProps` around for Android views.
This change makes sure that the `rawProps` field is only initialized under the feature flag that is responsible for enabling `MapBuffer` for prop diffing, potentially decreasing memory footprint and speeding up node initialization as JS props don't have to be converted to `folly::dynamic` anymore.
For layout animations, props rely on C++ values, so there's no need to update `rawProps` values either.
Changelog: [Internal][Android] - Do not init `rawProps` when mapbuffer serialization is used for ViewProps.
Reviewed By: mdvacca
Differential Revision: D33793044
fbshipit-source-id: 35873b10d3ca8b152b25344ef2c27aff9641846f
Summary:
Creates a mapbuffer from two ViewProp objects. This MapBuffer is used later instead of bag of props from JS to set the properties with platform ViewManager.
Changelog: [Internal] - Added MapBuffer diffing for ViewProps
Reviewed By: mdvacca
Differential Revision: D33735246
fbshipit-source-id: 10ad46251ea71aa844586624c888f5223fa44e57
Summary:
Parses a set of props previously missing from C++ representation (they weren't required for iOS and core processing before).
Changelog: [Internal] - Added missing fields for Android to C++ view props
Reviewed By: sammy-SC
Differential Revision: D33797489
fbshipit-source-id: 1625baa0c1a592fcef409a5f206496dff0368912
Summary:
Small performance improvement since we don't need to copy the char * into a string just for the sake of comparison.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34351387
fbshipit-source-id: 10163164f6e95ab0737e8f865c37d8f0c3500662
Summary:
Was trying out some behaviour when using the MapBuffer experiment and fixed some small issues.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34108859
fbshipit-source-id: 550ca0847419006ec17472cc4b70d38fc8d05396
Summary:
Adds support for Animated.Color with native driver for iOS. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into a SharedColor.
Followup changes will include support for platform colors.
Ran update_pods: https://www.internalfb.com/intern/wiki/React_Native/Preparing_to_Ship/Open_Source_Pods/
Changelog:
[iOS][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: sammy-SC
Differential Revision: D33860583
fbshipit-source-id: 990ad0f754a21e3939f2cb233bcfa793ef12eb14
Summary:
The views with touch event props are currently flattened by Fabric core, as we don't take event listeners into account when calculating whether the view should be flattened. This results in a confusing situation when components with touch event listeners (e.g. `<View onTouchStart={() => {}} /> `) or ones using `PanResponder` are either ignored (iOS) or cause a crash (Android).
This change passes touch event props to C++ layer and uses them to calculate whether the view node should be flattened or not. It also refactors events to be kept as a singular bitset with 32 bit (~`uint32_t`).
Changelog: [Changed][General] Avoid flattening nodes with event props
Reviewed By: sammy-SC
Differential Revision: D34005536
fbshipit-source-id: 96255b389a7bfff4aa208a96fd0c173d9edf1512
Summary:
This is pre-work for adding the v8 stack trace API support.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D34048366
fbshipit-source-id: 9d2b469767f7669cb428c61b215f193894892c03
Summary:
Changes to MapBuffer code in aaff15c...d287598 broke build for Windows. Errors included incompatible type conversions, the use of `__attribute__(__packed__)` which is only supported by GCC and Clang, and the usage of designated initializers which are only supported on C++20.
Changes here restore build on Windows.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix build break on Windows with ReactCommon
Pull Request resolved: https://github.com/facebook/react-native/pull/33047
Test Plan: React Native project built on Windows and passes react-native-windows repository pipeline. These edits are currently merged into the main branch of react-native-windows.
Reviewed By: ShikaSD
Differential Revision: D34101367
Pulled By: philIip
fbshipit-source-id: 1596365c2e92f377c6375805b33de5e1c7b78e66
Summary:
Removes duplicated code in SharedColor conversions. The original copy was done for the MapBuffer experiment, as the method was returning `folly::dynamic` instead of integer. Nothing prevents us from returning integer here directly, so we can keep one implementation.
Changelog: [Internal] - Removed duplicated SharedColor conversion for Android
Reviewed By: javache
Differential Revision: D33797490
fbshipit-source-id: 196657f0616e6cb7e987225b76328fe77fd6c28a
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Notifications
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34055503
fbshipit-source-id: 8c2dd1066ba2b68e395226f15954d303894d0365
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Responses
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34052619
fbshipit-source-id: d213ed41335b64bf3168a43ce043f2c57f05fc52
Summary:
changelog: [internal]
Rename method so it does not collide with immediates that already exist in React Native.
Reviewed By: javache
Differential Revision: D34041418
fbshipit-source-id: 0ae75b683983c3be50320b195a7068d7178b0ed8
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Messages
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34042008
fbshipit-source-id: 3a074e9840706ca977ff86d050e67b0dcea5c7ef
Summary:
changelog: [internal]
With multiple requests to the runtime, we need to make sure they are all granted before React continues with rendering. A boolean is not enough to track this. The first lambda that has VM will set it to false and subsequent requests will have to wait for React to finish rendering.
To prevent this, we can count how many lambdas are pending access to the runtime.
Reviewed By: ShikaSD
Differential Revision: D33792734
fbshipit-source-id: f785fae3575470179dd69acc6a466211b79b633b
Summary:
changelog: [internal]
pass raw ShadowNode instead of shared_ptr. Ownership is not transferred, shared_ptr is misleading.
Reviewed By: javache
Differential Revision: D33917010
fbshipit-source-id: 4d9fdd4b4e0376149f1719ad160b957de4afdce3
Summary:
[Hermes][Inspector] Implement the CDP API for calling a function on an object.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D33722301
fbshipit-source-id: da26e865cf29920be77c5c602dde1b443b4c64da
Summary:
D33740360 (16ed62a850) broke Explore VR on React Native. The app would go into a loop on boot and not finish mounting. This is probably a product code issue, but it's not a trivial issue to solve. Unlanding to unblock the RN migration.
Changelog:
[internal] internal
Reviewed By: mdvacca
Differential Revision: D33918026
fbshipit-source-id: cc77c70ece9994d82c91f7ae8783e959629e9cfb
Summary:
changelog: [internal]
React on web uses microtasks to schedule a synchronous update for discrete event. Microtasks are not yet available in React Native and as a fallback, React uses native scheduler and task with immediate priority. Until Microtasks are in place, React Native needs to make sure all immediate tasks are executed after it dispatches each event.
I tried to stay as close to [microtask standard](https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask) as I reasonably could.
Once microtasks on RN are shipped, this code can be removed.
Reviewed By: mdvacca
Differential Revision: D33742583
fbshipit-source-id: eddebb1bd5131ee056252faad48327a70de78a4a
Summary:
Calls to Inspector::evaluate() and Inspector::executeIfEnabled()
take a user-provided callback which are not try-guarded. This
means that, should the user code throw, the inspector's process
will likely die due to the unhandled exception. This change
makes sure that, if the user provided callback throws, then
the promise attached to those methods will be fulfilled by
an exception.
Change: [internal]
Reviewed By: avp
Differential Revision: D33852073
fbshipit-source-id: 7fbb6662b28d393a5d5b494c004aa9521e23ebb6
Summary:
The fix in this diff seems simple, but it took some time to understand why this change fixed the issue that views animated use native driver out from their parent's layout are not getting touch events.
We introduced `overflowInset` to RN Android a while back to give each shadow node extra information to cover all its children's layout. These values (left, top, right, bottom extensions from the view's own layout) help us improve hit-testing algorithm used in touch events. We could ignore all subtrees that the touch point not in their parent's overflowInset box.
However, this was not working for native animation. When `userNativeDriver` is on, all animation happens without Fabric knows anything about them. The overflowInset is out of date with the final animated layout, which caused the issue that we ignored the animated view as we thought it's not under the pointer.
Here is a playground demo (P476407654) for the issue:
https://pxl.cl/1XfPL
We've tried to fix this by passing the final animated values via `passthroughAnimatedPropExplicitValues` added in D32539976. This is a prop that will get merged into `style` prop for [animation component](https://fburl.com/code/jybzfgu5). The transform values were already applied when measuring layout in [Pressability](https://fburl.com/code/5mect2k3), which uses [LayoutableShadowNode](https://fburl.com/code/qh8fufrw). However, this is not the case for overflowInset calculation. Hence, the fix here is to apply the transform matrix in Yoga before calculating the overflowInset.
Changelog:
[Android][Fixed] - Fix overflowInset calculation by using transform values
Reviewed By: ShikaSD
Differential Revision: D33806030
fbshipit-source-id: e438618e3d6e5b0333cff9ff9919b841d73b2e9d
Summary:
This was a bug, we are fixing it.
Move pointerEvents from formsStacking -> formsView and we are also removing "onLayout" from formsStackingContext
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33846660
fbshipit-source-id: 6b65a9a7815972e34dafbc48b3d732d9b02d5e9f
Summary:
The flag was removed in https://www.internalfb.com/diff/D28467996 (2c5f68df46) but the code was not removed yet.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D33792884
fbshipit-source-id: 0ae5d904ca2ca94437ca63b495d41e47585fde33
Summary:
Changelog: [internal]
Add comments and avoid using shared_ptr unnecessarily.
Why note shared_ptr? Using shared_ptr suggests we are transferring ownership of object, which we are not.
Reviewed By: javache
Differential Revision: D33741836
fbshipit-source-id: 56ebb098e6185793f05e2bb587005bb0f093c0c9
Summary:
changelog: [internal]
Yielding in RuntimeScheduler is shipped. This diff removes the gating around it.
Reviewed By: sshic
Differential Revision: D33740360
fbshipit-source-id: 267372e81e66dda96e451435954a7c3546cc6fbe
Summary:
Refactors MapBuffer-related `primitives.h` to be namespaced with `MapBuffer` class, to avoid name collisions and confusion later on.
Most of the size constants are moved to relevant .cpp files or updated to use `sizeof`.
Additionally, adds a little bit of documentation about `MapBuffer` serialization format.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33662487
fbshipit-source-id: 5a7a2b1c7f2bb13ee1edfc5fae51ba88c34f0d3c
Summary:
Serializes type information along with key/value in MapBuffer, asserting the data type on Java side during read. At the moment, accessing value with incorrect will result in a crash.
Other changes:
Adds a `getType` method to verify types before accessing them.
Removes `null` as a type, as just not inserting value and checking for its existence with `hasKey` is more optimal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33656841
fbshipit-source-id: 23a78daa0d84704aab141088b5dfe881e9609472
Summary:
Removes the need to store keys in incremental order by sorting them after before inserting into MapBuffer.
Updates MapBuffer to support random access on C++ side, actually retrieving values by keys and not bucket index.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33611758
fbshipit-source-id: c81e970613c8ecc688bfacb29ba038bf081a0c0f
Summary:
Rename `_header` to `header_` to align with the C++ naming scheme we use.
Rename `readKey` to `readUnsignedShort` as purpose of the method have changed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33637127
fbshipit-source-id: a82f4d6c1b753b21e0567fbe919af98e4c78105d
Summary:
The struct is copied directly to the buffer, so it is safe to read it back.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33624036
fbshipit-source-id: 7ee2b28b815690ab471832c0c622a075b5dd7d78
Summary:
Replaces dynamic manually managed array with a vector of bytes, removing the need for managing memory manually.
This approach is a little bit slower than before, as vector is allocating memory more conservatively. This can be improved in the future by providing an estimate for the data size.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33611759
fbshipit-source-id: a0e5e57c4e413206a9f891cd5630ecc9088a9bf7
Summary:
Instead of copying integer values into key/value data array, this implementation keeps a structured vector of `Bucket` structs (which is sized to be serialized later).
This approach provides multiple benefits to modify and access buckets (e.g. sort them based on the key, allowing for out of order inserts (D33611758))
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D33601231
fbshipit-source-id: 62ace1374936cb504836d6eae672e909ea404e3f
Summary:
Benchmarks performance/correctness of mapbuffer with several different types of data
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33608299
fbshipit-source-id: 81b1e195aecac60ad1cc3ca416d1cf7b09feab32
Summary:
This method can produce unnecessary copy of the string, replacing it with reference to optimize.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33607765
fbshipit-source-id: e04eddffec063c0c8e173bfdf690e7b8e1050525
Summary:
Cleans up `ReadableMapBuffer` APIs and migrates to use `std::vector` instead of raw pointer array.
Also uses `fbjni` utility to allocate the bytes instead of making manual JNI calls.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33513027
fbshipit-source-id: afe7d320d12830503de4c9994117d849f0b25245
Summary:
Replaces raw array pointer inside `MapBuffer` with `std::vector`, which is more conventional "safer" way of storing dynamically sized arrays.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33512115
fbshipit-source-id: d875a2240f7938fd35c4c3ae0e7e91dc7456ff32
Summary:
TurboModules: use weakSelf for block sent to main thread.
Changelog:
[iOS][Fixed] - Use weakSelf in objc block instead of self.
Reviewed By: RSNara
Differential Revision: D33488938
fbshipit-source-id: d03c98fb59fbd1fc4b67686251ebec541e5d3e6c
Summary:
changelog: [internal]
You can read more about this rule on https://clang.llvm.org/extra/clang-tidy/checks/modernize-pass-by-value.html
# Isn't it wasteful to copy? Isn't reference more efficient?
This rule of thumb is no longer true since C++11 with move semantics. Let's look at some examples.
# Option one
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
private:
std::string text_;
};
```
By using reference here, we prevent the caller from using rvalue to and avoiding copy. Regardless of what the caller passes in, copy always happens.
# Option two
```
class TextHolder
{
public:
TextBox(std::string const &text) : text_(text) {}
TextBox(std::string &&text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, we provide two constructors, one for const reference and one for rvalue reference. This gives the caller option to avoid copy. But now we have two constructors, which is not ideal.
# Option three (what we do in this diff)
```
class TextHolder
{
public:
TextBox(std::string text) : text_(std::move(text)) {}
private:
std::string text_;
};
```
Here, the caller has option to avoid copy and we only have single constructor.
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D33276841
fbshipit-source-id: 619d5123d2e28937b22874650366629f24f20a63
Summary:
changelog: [internal]
For some reason, using `TextLayoutManager::Shared` in `TextInputShadowNode` trips up clang tidy linter. We have a plan to move away from `*::Shared` anyway, so let's remove it from `TextInputShadowNode` now.
Why do we want to move away from `*::Shared`?
Using `TextLayoutManager::Shared` is confusing for people unfamiliar with Fabric's codebase. It expresses a concept of immutability but uses term `shared`. Term shared is already used in C++ `std::shared_ptr`.
Reviewed By: fkgozali
Differential Revision: D33186422
fbshipit-source-id: 10ee588735997f5fedc372a1d1e3d9cd9684178a
Summary:
Just clarifying the purpose of this library.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D33245053
fbshipit-source-id: b4325415774ca33b34b5ba53d222a19f88e2175f
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
changelog: [internal]
In an effort to make our codebase more approachable, I'm enabling more clang-tidy rules.
Read more about modernize-avoid-c-arrays in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-c-arrays.html
Reviewed By: ShikaSD
Differential Revision: D33187162
fbshipit-source-id: c6b3888f67d095274bb492a01132985ae506c0d5
Summary:
changelog: [internal]
I will be enabling more clang tidy rules in Fabric to make it easier for new contributors and standardise the codebase. \
You can read more about the rule in https://clang.llvm.org/extra/clang-tidy/checks/modernize-avoid-bind.html
Reviewed By: ShikaSD
Differential Revision: D33162192
fbshipit-source-id: b4bb332f3134c42c49559a8baf10aeb7a7fdd87f
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
changelog: [internal]
Only execute tasks that are expired when in synchronous mode.
Reviewed By: philIip
Differential Revision: D33062746
fbshipit-source-id: 1825cb572202d1f5dc18eb2b481dd3c20e8e91ba
Summary:
Allows `CxxModule` objects to set their `instance_` member before `getMethods()` is invoked, allowing for the `Method` callbacks to capture a weak reference to `getInstance()` if needed.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Set CxxModules' Instance before retrieving their Method vector.
Pull Request resolved: https://github.com/facebook/react-native/pull/32719
Test Plan: Ensure this statement swap does not break any scenarios with existing CI validation.
Reviewed By: JoshuaGross
Differential Revision: D32955616
Pulled By: genkikondo
fbshipit-source-id: fd7a23ca2c12c01882ff1600f5aef86b1fe4a984
Summary:
changelog: [internal]
Just moving code that doesn't belong to UIManagerBinding out of the class.
Reviewed By: philIip
Differential Revision: D33060412
fbshipit-source-id: 2d54929072cef14fd1fa6b70bde382ae21ecff45
Summary:
Fabric uses a cache where it stores the result of the text measurement in C++ (to avoid unnecessary text measurement that are very costly). This cache has a "max size" of 256 and this size is not enough to store all the texts we have in the screen
In my tests, the amount of texts being measured are ~290 and after scrolling many times they increase to 611.
This diff increases the size of the TextMeasure to 1024 for users in the experiment. As a result this improves performance of HoverEvents by +5x times (see test plan)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33112788
fbshipit-source-id: e15feecf0f54da62b252892d37a64fb4ead29e22
Summary:
Applies suggestions from default preset that make sense in our codebase
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33010231
fbshipit-source-id: 6bc9edf01fd9bd9938d211e3494dd1a127b24eaa
Summary:
Follow up to https://github.com/facebook/react-native/issues/32683 to also link hermes-inspector statically.
## Changelog
[Android] [Fix] - Static link for hermes-inspector
Pull Request resolved: https://github.com/facebook/react-native/pull/32694
Test Plan: Tested a clean build and made sure hermes-inspector.so doesn't exist anymore.
Reviewed By: cortinico
Differential Revision: D32791208
Pulled By: ShikaSD
fbshipit-source-id: 6076b263469b9e2c6176d488d13292d4f1731dcc
Summary:
changelog: [internal]
Provide `UIManager` to `UIManagerBinding` in constructor to make the API safer.
Reviewed By: philIip
Differential Revision: D32668892
fbshipit-source-id: a15cd295196a60c3f46997e59c05c4f90503e18d
Summary:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
Summary:
changelog: [internal]
Event `onChangeText` does not exist in TextInput. Let's remove this method to avoid confusion.
Reviewed By: philIip
Differential Revision: D32882056
fbshipit-source-id: 37eb260b84dd7d6cce412ce1bc39c0cbf9cab112
Summary:
changelog: [internal]
Exposes a new flag on RuntimeScheduler: `unstable_getIsSynchronous`. Flag indicates if the current code is run synchronously and therefore commit phase should be synchronous.
Unit tests will be added later, to keep this diff short. This code path is not executed yet.
Reviewed By: mdvacca, ShikaSD
Differential Revision: D32677814
fbshipit-source-id: e01d4fff7e716d627ff99fe104965851138c3aef
Summary:
This class is not used and can be safely deleted
Changelog: [Internal] Delete unused Android event emitter
Reviewed By: mdvacca
Differential Revision: D32916706
fbshipit-source-id: 6dceb6b6ed9d201d96454bf0d646853c5c893d59
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary:
changelog: [internal]
UIManager::animationTick is thread safe. Let's make it obvious by marking the method const.
Reviewed By: javache
Differential Revision: D32669102
fbshipit-source-id: 49e35d0f0a5c5d1b03baa1cbf9cdece082909e85
Summary:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here b8f415eb6c/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk (L20). There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
If `value` is of type `float`, it will still fall through to the `react_native_assert` below, exploding. The `map` type is handled correctly.
Changelog: [Internal][Fixed] Fix fromRawValue(EdgeInsets) from single float case falling through to float array and exploding
Reviewed By: javache
Differential Revision: D32648848
fbshipit-source-id: e70cddd291a8f52d6ee3de5fef11b0bb7aee92cd
Summary:
Removes extra .so files by merging built-in components into libfabricjni.so
These components shouldn't be referenced in outside modules, so merging them is trivial atm.
Changelog:
[Internal][Android] - Compile native components into static libraries
Reviewed By: cortinico
Differential Revision: D32677572
fbshipit-source-id: fc1a6c5a2832ee49e438c30856562f85677514ea
Summary:
Changelog: [internal]
Nothing was using `stop` parameter, let's get rid of it.
Reviewed By: philIip
Differential Revision: D32669018
fbshipit-source-id: dc2d52048a2f7dd3785dd959270087001c778962
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
AGP 7.x is changing the path where we can find
the precompiled static libraries. Therefore is getting complicated
to share prebuilt `.a` files. I'm updating `libruntimeexecutor` to be
a shared library instead so this will solve this issue for now.
Changelog:
[Internal] [Changed] - Update libruntimeexector to be a shared lib rather than a static lib
Reviewed By: ShikaSD
Differential Revision: D32646112
fbshipit-source-id: ce42e930076c1d3b5f54f3d8adcca1c38909d0fb
Summary:
similar to android, we want to handle removing dropped surfaces. in this diff, we add the API to do so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32557069
fbshipit-source-id: 2487c459df3f1f412ad0da77568d6c0ab0a1298c
Summary:
This diff prevents view flattening for views that are handling some events in the JS side
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253124
fbshipit-source-id: acda2b12287f0a9c39a810b23a101765093ba217
Summary:
This diff updates the internals of Fabric to add support for onEnter/onExit/onMove events.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253128
fbshipit-source-id: 5b30e927bda0328ba1332801f66a6caba77f949b
Summary:
resolving issue in https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
we didn't hook up the onScroll event to the fabric text input component yet, so this stack does that
in this diff, we add the onScroll event to the event emitter
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D32479450
fbshipit-source-id: 3ac0e6f87a4bf391e3ceee24b5765e3e41ecc59d
Summary:
This messes with python version selection. At least based on
the comments, it is no longer needed, as /opt/local/bin appears to be
empty on my devserver and on a sandcastle host.
D32337004 revealed the problem. T105920600 has some more context. I couldn't repro locally, so D32451858 is a control (which I expect to fail tests) to confirm that this fixes the test failures.
#utd-hermes
Reviewed By: neildhar
Differential Revision: D32451851
fbshipit-source-id: 4c9c04571154d9ce4e5a3059d98e043865b76f78
Summary:
Changelog:
[Internal][Fixed] - I have been reading this header file recently and discovered some typos
Reviewed By: kodafb
Differential Revision: D32455214
fbshipit-source-id: c27291943476014b787ee1641fd8642056bdbc5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32585
D31631766 (b60e229d7f) unified compiler flags for all RN targets, which also enabled `-Werror` for this target. This causes issues on Windows where some warnings are extremely noisy and unhelpful and causes our Hermes+JSInspector build to fail
Reviewed By: rshest
Differential Revision: D32244577
fbshipit-source-id: 7cda346c46d21ff03490bae705759c502f6cf29f
Summary:
Fixed a bug in `react_native_assert` that was not effectively letting the app
call `abort()`. The app was actually printing on log twice.
Ref: https://developer.android.com/ndk/reference/group/logging#__android_log_assert
Changelog:
[Android] [Changed] - Let react_native_assert really abort the app
Reviewed By: JoshuaGross
Differential Revision: D32204080
fbshipit-source-id: ca16c50aaf4e41a2318277c233be0e944b2ad8f1
Summary:
This pull request aims to remove iOS 11 availability check which is no longer needed.
The minimum iOS deployment target for React Native is iOS 11 but we still have iOS 11 version check like below.
```
if (available(iOS 11.0, *)) {
```
This is a continuation pull request of https://github.com/facebook/react-native/pull/32151
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Remove iOS 11 availability check
Pull Request resolved: https://github.com/facebook/react-native/pull/32488
Reviewed By: yungsters
Differential Revision: D32006312
Pulled By: ryancat
fbshipit-source-id: 0ee6579e433a15d3d220a52d2ccd6931b0513971
Summary:
D31809012 (f7e4c07c84) introduced a condition where codegen files weren't generated in a correct order so the build fails in `yarn test-ios` if it was a first time to run the command. So it broke ci/circleci: test_ios_unit_hermes.
In this diff
Pull Request resolved: https://github.com/facebook/react-native/pull/32480
Changelog: [intermal]
Reviewed By: cortinico
Differential Revision: D31953580
fbshipit-source-id: db854d6cfed8167dc4aae2667d379738bc261cfe
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
The [first implementation of `TextAttributes` in Fabric](62576bcb78) included two separate props instead of `textDecorationStyle`: `textDecorationLineStyle` (single, double, ...) and `textDecorationLinePattern` (dot, dash, dotdash, ...). These two props were implemented in C++ and iOS but never supported in JS.
Pre-Fabric (and CSS) on the other hand use a single prop `textDecorationStyle: 'solid' | 'double' | 'dotted' | 'dashed'`.
This diff implements this same API in Fabric, and removes the unused `textDecorationLineStyle` and `textDecorationLinePattern` props.
Changelog:
[iOS][Fixed] - Implement `textDecorationStyle` on iOS and remove unused `textDecorationLineStyle` and `textDecorationLinePattern` from Fabric.
Reviewed By: dmitryrykun
Differential Revision: D31617598
fbshipit-source-id: f5173e7ecdd31aafa0e5f0e50137eefa0505e007
Summary:
These dynamic_casts aren't really giving us much (they have never fired once in dev! and don't run in prod anyway). They also prevent us from disabling RTTI. So, let's get rid of them.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31634895
fbshipit-source-id: 4a9b259837127feb324f64fa3e9e23eb1cc481a6
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32247
I don't think we need both libc++ and libstdc++.
allow-large-files
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30950943
fbshipit-source-id: d0669815ff59c3e9ac45954a4a11930d1bc3959f
Summary:
changelog: [internal]
Catch JavaScript errors and forward them to `ErrorUtils` in *RuntimeScheduler*. This makes sure that JS errors are handled by ErrorUtils and do not bubble up to bridge.
Reviewed By: philIip
Differential Revision: D31429001
fbshipit-source-id: 50f865872e4cd3ba180056099ff40f5962ee7a77
Summary:
changelog: [internal]
This is a pre-condition to get rid of `shared_ptr` from `EventEmitterWrapper`. Also saves us a few copies of shared_ptr, this is negligible though.
Reviewed By: mdvacca
Differential Revision: D31307048
fbshipit-source-id: b84654bed2359b66faf3995795e135e88fe51cb6
Summary:
For iOS, event category deduction is done from the C++ code, but the touch events are handled on Java layer in Android. This change exposes the category parameter through the `EventEmitterWrapper` called from Java, allowing to define category for events in the future.
Changelog:
[Internal] - Expose event category through JNI
Reviewed By: mdvacca
Differential Revision: D31205587
fbshipit-source-id: f2373ce18464b01ac08eb87df8f421b33d100be2
Summary:
Original commit changeset: 2acd52ae5873
This original change was made in D26705430 (b08362ade5) and D26705429 (69feed518d). The intention was to change the timestamp definition to make touch telemetry easier, but this is (1) unnecessary and (2) causes other issues.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D31183734
fbshipit-source-id: 6af669bb5696896b43fa4508af1171446d62c6d6
Summary:
Changelog: [Internal]
Small optimization, we can avoid evaluating some properties if `formsStackingContext` is already set, because the end-result is always true.
Reviewed By: sammy-SC
Differential Revision: D30990925
fbshipit-source-id: 08f500aa4b75446a6c644e8821f84dbfccbfebb6
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Joshua Gross
Nikita Lutsenko
Pieter De Baets
Kudo Chien
Scott Kyle
Vincent Riemer
Janic Duplessis
Nicola Corti
Neil Dhar
Michael Lee (Engineering)
Rubén Norte
Luna Wei
Anandraj Govindan
Sam Zhou
Baoshuo Ren
Ramanpreet Nara
Oleksandr Melnykov
MaeIg
Krzysztof Magiera
Richard Howell
Anand Bashyam
John Porto
NikoAri
Hugo Cuvillier
Alex Landau
Chris Olszewski
Andrei Shikov
Xin Chen
CodemodService Bot
Joachim Reiersen
Christoph Purrer
Tatiana Kapos
Phillip Pan
Arthur Kushka
Xavier Deguillard
Samuel Susla
caioagiani
Richard Barnes
Daniel Andersson
Diego Pasquali
Gilson Takaasi Gil
Dimitri Bouche
Gal Shirin
David Vacca
Paige Sun
Genki Kondo
Chiara Mooney
Raphael Herouart
Felipe Perez
Moses DeJong
Andres Suarez
Kevin Gozali
Julio C. Rocha
Nawbc
Marc Horowitz
Ken Tominaga
Tim Yung
Sota Ogo
Rob Hogan
