Summary:
This diff changes how we expose UIManager to JavaScript realm and control ownership of it. This change should improve reliability and a thread-safety.
UIManagerBinding is a HostObject which consolidate ownership of UIManager. Now JavaScript's GC controls its lifetime which eliminates the possibility of calling some JS facing methods of UIManager using a dangling pointer.
Besides that, all API now imply that if the caller has a reference to jsi::Runtime, it calls the method on the proper thread (it's an implication of RuntimeExecutor design).
Reviewed By: sahrens
Differential Revision: D12876745
fbshipit-source-id: eb8c70317460df5b14e45031ad15fc6c8e5b5ce3
Summary: We need to decouple this from actual JSI/UIManagerBinding implementation to make them more maintainable.
Reviewed By: sahrens
Differential Revision: D12876742
fbshipit-source-id: 30cad69d0a9761e2aa82f31d180e4b5a40cedb61
Summary: This is more usable (because it allows to use `->` operator) and safe (const-style) methods replacing old `operator[]` methods.
Reviewed By: mdvacca
Differential Revision: D12876744
fbshipit-source-id: 8ea7398c9777f8be3e88db873ec00915d0761615
Summary:
We double down on JSI in Fabric. So, practically, JSI is now a hard dependency for Fabric. I hope it's for good.
Now `jsi::Runtime` is coupled with scheduling via `EventExecuter`, so we have to make `jsi::Runtime` a part of `EventBeat` to proxy runtime reference to bindgings.
Reviewed By: sahrens
Differential Revision: D12837225
fbshipit-source-id: 98edc33d6a3358e6c2905f2f03ce0004a9ca0503
Summary: Apparently, the standard does not guarantee that the vector is empty after moving from it. So, let's clear it explicitly instead of asserting the emptiness.
Reviewed By: sahrens
Differential Revision: D12837227
fbshipit-source-id: 85dff6848707f4204f4c79be173064547e83c63e
Summary: React bytecode is kind of a different thing that sebmarkbage already has in mind so lets keep the namespace separate.
Reviewed By: mdvacca
Differential Revision: D12896293
fbshipit-source-id: e0f266da6e7a051bcf5defea49b958452342754d
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
* Adds parent tag as param for createNode in place of explicit appendChild commands.
* Adds version info to bytecode
* Adds native conditional support:
Conditionals are represented in product code with the new `NativeConditional` React
component. It takes params necessary to construct a native function call, and takes
a render prop as a child that passes the value of the native call as an arg. In
prod, the component would actually call the native module and render with that value,
but in jest we render for *both* true and false and set them as children
of a new jest-only primitive/host component which we special-case and generate a
special command with `OP_CODE.conditional`, generate the appropriate bytecode commands
for each branch, and embed them as args in the conditional OP_CODE command. When
evaluating the bytecode, only one set of commands is executed, based on the native
module value (which is evaluated with another new opcode which computes the value
and stuffs it in a "register").
Obviously generating this bytecode is kind of a cludge compared to prepack, but
when I asked @[501709947:Dominic] about it, he said they had no bytecode spec right
now, so I'm running ahead with this prototype. The main thing I'm focused on is
the C++/RN bytecode interpretter - this jest stuff is just a way to generate bytecode
for it to consume which could be replaced or augmented with many other approaches,
such as prepack, server rendering, etc.
Also piggybacked a bunch of other cleanup.
Reviewed By: shergin
Differential Revision: D10277121
fbshipit-source-id: 15d3217a59ef481b574c742d17d8a7dc893cba90
Summary: The old implementation of folly::none inadvertently allowed disengaging an optional by writing `op = nullptr`. Disallow that and require `op = folly::none`.
Reviewed By: yfeldblum
Differential Revision: D12884724
fbshipit-source-id: b17bcf00b245069d8ea2d9bc3703b0fdcaa85c07
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
Summary:
Makes the delta bundle data structures more consistent.
The changes are as follows:
* There are now two types of JSON bundles that can be downloaded from the delta endpoint. Base bundles (`Bundle` type), and Delta bundles (`DeltaBundle` type).
* The `reset` boolean is renamed to `base`.
* `pre` and `post` properties are now strings.
* Only `Bundle` can define `pre` and `post` properties.
* The `delta` property is renamed to `modules`.
* Deleted modules are now listed inside of the `deleted` property, which is only defined by `DeltaBundle`.
Reviewed By: mjesun
Differential Revision: D10446831
fbshipit-source-id: 40e229a2811d48950f0bad8dd341ece189089e9b
Summary:
We were not accounting for shutdown properly when counting
jsi Objects at shutdown.
Reviewed By: danzimm
Differential Revision: D10451732
fbshipit-source-id: 7f0eb357aa3a011b7b2a97e44c22549e06e311c5
Summary: ImageManager is used to update the LocalData of Image views, as part of this process we call ImageManager::requestImage in cross platform code. Event if Android doesn't use ImageRequest we need to return an empty non-operation version of this object.
Reviewed By: shergin
Differential Revision: D10429663
fbshipit-source-id: 3621ece72f7291e2e6ab6a84b238ac16b595fc18
Summary:
`extern "C"` disables name mangling, hence input parameter types does not influence the name. That makes it impossible to have several equality operators with `extern "C"` linkage (for different types).
One such operator is defined in Windows SDK, in `guiddef.h`. It in turn is included in `winnt.h` inside `extern "C" { ... }` block. Trying to compile file which both is dependent both on `winnt.h` and `Yoga.h` results in:
```
Yoga.h(50): error C2733: 'operator ==': second C linkage of overloaded function not allowed
guiddef.h(192): note: see declaration of 'operator =='
```
In general it doesn't make much sense to have cpp specific operator to have `extern "C"` linkage, so the change doesn't introduce any controlling flag (mangling on/off).
Note that it's breaking binary compatibility and yoga library should be rebuilt if those operators are used.
Reviewed By: milend
Differential Revision: D10418395
fbshipit-source-id: 2f1cccff26165e638b9a07eece07d94fccfa5e5a
Summary:
This diff includes a few changes:
1. Move the headers inside `jsiexecutor` into `jsiexecutor/jsireact`. As far as I'm aware, the Android ndk build system isn't flexible enough to support header namespaces, so we can't just expose the headers inside the `jsiexecutor` directory under the `jsireact` namespace. Therefore, I moved the headers to `jsiexecutor/jsireact`, and added `jsiexecutor` to the header search path. This was the easiest way to simulate `jsireact` namespace.
2. Setup the Android.mk files to get RNTester compiling and running.
3. Introduce a `jscexecutor` module to make `JSCExecutor.java` execute without throwing.
**Note:** Moving the header files inside `jsiexecutor` probably breaks the iOS builds and internal builds. I'll fix those in subsequent diffs on this stack.
Reviewed By: shergin
Differential Revision: D9995429
fbshipit-source-id: 418a4ee91f585842c5e317af2f300227a51e9ba8
Summary: JSI doesn't use any of this.
Reviewed By: RSNara
Differential Revision: D10229167
fbshipit-source-id: 9eaa288a1d62bafb3ff0626f9f8430e699fdad4a
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary:
Removing entire files will be the next diff
@public
Reviewed By: fkgozali
Differential Revision: D9328239
fbshipit-source-id: 083847d3b841a3c7bfa751a82e8cc16bd112bace
Summary:
This is similar in function to the old JSCExecutor, but uses the more abstract JSI API to interact with the JSVM.
@public
Reviewed By: axe-fb
Differential Revision: D9328241
fbshipit-source-id: 3212ff4f43d0589a70d7bebc4d463d4433590f1d
Summary:
This diff is an implementation of jsi::Runtime which uses JSC as the virtual machine. All of the JSC-specific details are encapsulated here.
@public
Reviewed By: RSNara
Differential Revision: D9328242
fbshipit-source-id: be3c7bed161916c1cb9a48182600b558f054eadc
Summary: This will help abstract the JS engine from React Native
Reviewed By: hramos
Differential Revision: D9328237
fbshipit-source-id: 7b34f55f28e43d83ba24d22e83e836c92ca737a9
Summary:
The first implementation of EventEmitter's enable/disable feature didn't not provide a way to enable an object after it was disabled.
Apparently, we need this functionality due that fact that all nodes of the same family share same event emitter.
Reviewed By: mdvacca
Differential Revision: D10395849
fbshipit-source-id: 0eba54f0bb7ded35d64afb6559e6e27208c2b577
Summary:
Trivial.
We have to proxy layout directions as well as min and max sizes to RootNode's Props to properly communicate the constrains to Yoga.
Reviewed By: sahrens
Differential Revision: D10387798
fbshipit-source-id: a02ec0a20b3ef28f6230738e5b3a4a2b0b8e0961
Summary: An `AttributedString` object generated by a cross-platform layer of React Native must have already resolved text styles to make the actual resulting text identical across platforms. To do so we have to have a unified default.
Reviewed By: sahrens
Differential Revision: D10287725
fbshipit-source-id: e8c62b33496be34146182baccd0009d3624a7fe5
Summary: This might be useful to specify some default props.
Reviewed By: sahrens
Differential Revision: D10284657
fbshipit-source-id: b6fbdc6bab75697af67bdbb5d06eb3309500ab8c
Summary: We didn't have support for them... and now we have it.
Reviewed By: sahrens
Differential Revision: D10280430
fbshipit-source-id: 7275d4617ed3994366f673a17c24b823293d7092
Summary: This diff fixes the release of ImageRequest object. The responseFutureSplitter_ can be destroyed by the time ~ImageRequest is executed. See P60163877 for original crash (this crash was reproducible when reloading or closing a Fabric screen that contains several images.
Reviewed By: shergin
Differential Revision: D10282207
fbshipit-source-id: 4f0894959e54f6d15b98e216df102e764866e387
Summary:
Fixes#815
Imagine a node with this style: `{ paddingHorizontal: 10, paddingStart: 0 }`.
After running layout on this node, we expect its computed `paddingStart` to be `0`. However, it is actually `10`.
Consider the expression `paddingEdgeStart.getValue() > 0.0f` in [`getLeadingPadding`](328ec7dc4d/yoga/YGNode.cpp (L461)). Why is `0` handled like a negative number rather than a positive number? I suspect this should be `>=` so `0` is handled like the positive numbers (this is how `getTrailingPadding` works).
It looks like 3a82d2b1a8?diff=unified&w=1#diff-07b4949bf42749fde386e769ff08a124 changed the operator from `>=` to `>` in `getLeadingPadding`. I suspect it was a mistake. `getTrailingPadding` still uses `>=`.
I manually verified this using the code in #815 and added some unit tests to catch this bug and other similar issues.
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/yoga/pull/816
Reviewed By: priteshrnandgaonkar
Differential Revision: D10282617
Pulled By: shergin
fbshipit-source-id: 2ab2874ae39d9454308a020a960ace85573fe777
Summary: missing header and platform. attributedstring builds now, but still fails because of T34990592
Reviewed By: mdvacca
Differential Revision: D10349210
fbshipit-source-id: dcd163df9ac9a4fcb36399cb9f93dbf1b33c062d
Summary:
`YGRoundValueToPixelGrid` currently rounds negative numbers incorrectly. For example:
```
YGRoundValueToPixelGrid(-2.2, 1.0, /* ceil */ false, /* floor */ true) = -2.0
```
However, that operation is supposed to take the floor of the number so the result should acutally be `-3.0`.
There's a detailed comment in `YGRoundValueToPixelGrid` about the fix and why it works.
A symptom that manifested because of this bug is that text nodes could get smaller and smaller on each layout pass. For details see https://github.com/facebook/yoga/issues/824.
Fixes#824
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/yoga/pull/825
Reviewed By: priteshrnandgaonkar
Differential Revision: D10282064
Pulled By: shergin
fbshipit-source-id: 16ca966e6cb0cfc88b1dbf4ba31e7b1dbe1f2049
Summary: Simplies UIManager a bit and some other tweaks
Reviewed By: shergin
Differential Revision: D10211883
fbshipit-source-id: 93ab23dd2baab2fdc6d9c54e976b001a19efab7f
Summary:
This consists of several fixes:
- Some of the C++ functions called by the tests were missing `WIN_EXPORT`
- It looks like Yoga was changed to round up after `TestMeasureFuncWithFloat` was written. Here's the function call that results in the rounding: 357ca78f9f/yoga/Yoga.cpp (L4019-L4026)
- The format of the result of the `Print` method was changed after `TestPrint` was written.
Pull Request resolved: https://github.com/facebook/yoga/pull/818
Differential Revision: D10282902
Pulled By: shergin
fbshipit-source-id: a5fd732a7dbff1a704cbafbfc95ae3e0c0a0cdd8
Summary: This diff avoids the serialization of color that are set as: "UndefinedColor". This allows the text rendering system to set the default color in the native side
Reviewed By: shergin
Differential Revision: D10275834
fbshipit-source-id: b81c7a5995bef65e04a246d99f44ff10cb20f548
Summary: This diff enables the onPress event for TextViews that render RawText
Reviewed By: shergin
Differential Revision: D10222183
fbshipit-source-id: 4b6a6ad548286453f7dd3a14a5e4ee453a55b923
Summary: This diff enables view flattening for Android when using Fabric.
Reviewed By: shergin
Differential Revision: D10254678
fbshipit-source-id: cc7acaa38a6d01e112ba0e8a92db61cdeefbffee
Summary: This diff introduces the collapsable props in the viewProps. This prop is used in product code to prevent specific Views to be removed from the view hierarchy
Reviewed By: shergin
Differential Revision: D10254679
fbshipit-source-id: 637665b8998a86e29e839eb6d405a0fac354c8d3
Summary: Previsouly, we basically didn't support Accessibility at all.
Reviewed By: mdvacca
Differential Revision: D10250635
fbshipit-source-id: d33eed8f56374f57310654653f41c312cb5942e6
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: Quite obviously, having a `complete` method which accepts only `newRootShadowNode` was a baaad idea. When we `complete` or `commit` we always have to have two nodes (before and after). And only after layout and right before swapping (and acquiring the mutex) we have to verify that *current* root node is still the same as it was when we initialized the transaction (if not, we have to abort).
Reviewed By: mdvacca
Differential Revision: D10201902
fbshipit-source-id: 15adc78c5d31d6fd39fd7fc6e53203a5539717a8
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary: With new `ShadowTree::getRootShadowNode()` method all access to rootShadowNode_ is protected by commit mutex.
Reviewed By: mdvacca
Differential Revision: D10159456
fbshipit-source-id: 0bc8676ca2564a8ef95d60e912356e99d9f172c1
Summary:
Calling `uninstall` synchnously was a bad idea. Unfortunatelly, even if it illuminate possible race condition during uninstallation, sometimes it deadlock.
It's not clear for now how to solve both problems without introducting another layer of indirection between UIManager and JSI.
Reviewed By: mdvacca
Differential Revision: D10081500
fbshipit-source-id: 90d8120603929a8219a3e606d8b3527e297b13ce
Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
Reviewed By: sahrens
Differential Revision: D10081501
fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
Summary: In some cases we have to have a way to notify a EventBeat consumer that the beat cannot be (and will not be) delivered, so we introducing special API for that.
Reviewed By: mdvacca
Differential Revision: D10081503
fbshipit-source-id: 4c5a392d32572f426e3744bdba797efcd29b8cb4
Summary:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Summary: This diff unifies the 'handling' of the top prefix in the EventEmitter.cpp class
Reviewed By: shergin
Differential Revision: D10149497
fbshipit-source-id: d0ddbbbeefe3790b414b101da47582161354c971
Summary: This diff renames com.facebook.fbreact.fabric.UIManager to FabricUIManager, this is done in order to avoid confusion with com.facebook.react.bridge.UIManager
Reviewed By: shergin
Differential Revision: D10128635
fbshipit-source-id: 0cb874ec1ba698077d750214f1d25004065c2f59
Summary: This diff exposes the method EventEmitter.dispatchEvent as public in order to be able to access it from the android side.
Reviewed By: shergin
Differential Revision: D10127509
fbshipit-source-id: d6ddf59c654a91fdeed5fba867ca31d6de96d607
Summary: This change implements `onLayoutOnly` for regular bare <View> component (*not* for its descendants!) After this view flattening is actually starting working for all platforms.
Reviewed By: mdvacca
Differential Revision: D9511001
fbshipit-source-id: 3562dd1b7570a064150f100cc2e1bc4220b81290
Summary:
... instead of using direction access to `ygNode.getLayout()` object.
Suddenly, YGLayout object that YGNode exposes contains unresolved/directional-unaware styles. To get resolved directional-aware styles we have to use functions from Yoga.h.
I am not happy with this solution, I will try to implement something like `ygNode.getResolvedLayout()` and use that instead.
This change fixes strange missing horizontal padding around some views.
Reviewed By: mdvacca
Differential Revision: D10112049
fbshipit-source-id: 4b6ef39d8dd34e78a4592962e8af4eeaa5028768
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary: We have to uninstall UIManager synchronously to avoid a race condition when JS is capable to call already deallocated UIManager.
Reviewed By: mdvacca
Differential Revision: D10033406
fbshipit-source-id: 194d1ae2dd5ab09b036b1c165de289ada8e66014
Summary:
There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
Reviewed By: mdvacca
Differential Revision: D9999336
fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
Summary: This is the last step before making JSIUIManagerInstaller a direct dependency of UIManager (and making UIManager installation process completely seamless/platform-agnostic).
Reviewed By: mdvacca
Differential Revision: D9995781
fbshipit-source-id: 6f8c7177495b01ebaac1dbe330f49dce2e2a552c
Summary:
EventBeatBasedExecutor is an executor derived from EventBeat and using EventBeat to ensure proper threading.
Why do we need yet another executor? Because otherwise, we have to make it platform specific-dependency that each platform-specific implementation has to implement and provide. We already have all that we need in already provided EventBeat, so we can just convert that into simple executor in a platform-agnostic way.
Reviewed By: mdvacca
Differential Revision: D9995783
fbshipit-source-id: f8aa72a9744e50ebecbea9ad0e2546f41f5358f2
Summary: UIManager now can install and uninstall itself calling a functions that are provided as constructor arguments.
Reviewed By: mdvacca
Differential Revision: D9931329
fbshipit-source-id: b8d2d9925b0e2db0fed44bdf2e185d198fabd5ee
Summary: As it mentioned in the comment, we have to commit an empty tree as part of cleaning up Surface.
Reviewed By: mdvacca
Differential Revision: D9931320
fbshipit-source-id: 04e780bafdb917adeb89f2edef2dc0348b2a4d4a
Summary: This diff adds support for the ActivityIndicator component into the Android Fabric C++ implementation
Reviewed By: shergin
Differential Revision: D9781846
fbshipit-source-id: 952d72556983955875198ac3b7eece6868bc4ae8
Summary: This diff adds support for image views in Android
Reviewed By: shergin
Differential Revision: D9757712
fbshipit-source-id: 8d33e04c8ac4a670af6ca49bb3b9dccc69d52e40
Summary: This diff fixes the compilation error: "implicit instantiation of undefined template std::hash" when using TextAttributes in Android
Reviewed By: shergin
Differential Revision: D9849407
fbshipit-source-id: 7fcb94b1d4f7715d8037ecbf302d8f345e99e9fd
Summary: This diff introduces the concept of Local Data in Android Fabric C++ and as an example we uses it to implement Text View.
Reviewed By: shergin
Differential Revision: D9583970
fbshipit-source-id: ab7478b16ef4327ff574ca1467870ab9cb684ea0
Summary: In this diff I added support to be able to measure C++ shadowNode in Android. As an example I implemented the measurement of TextViews
Reviewed By: shergin
Differential Revision: D9583972
fbshipit-source-id: 1344782d4c586c94a4576b18a4acfa4775e46952
Summary: This diff introduces a way to convert ParagraphLocalData object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801892
fbshipit-source-id: e50217042a216ea67f28178bb80b136cbb8fb195
Summary: This diff introduces a way to convert AttributedString object to dynamic objects
Reviewed By: shergin
Differential Revision: D9801438
fbshipit-source-id: b762f54917ae90bf53c7f9d07f63b876d1265ece
Summary: This diff introduces a way to convert TextAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9800636
fbshipit-source-id: 592f1cb60a00d3beaecee221259e8914731049d4
Summary: This diff introduces a way to convert ParagrapgAttributes object to dynamic objects
Reviewed By: shergin
Differential Revision: D9798895
fbshipit-source-id: 5b139a079c8681749c3e13938482b47e4153019d
Summary:
A bunch of different things was changed, but the most important (and need) change is that `UIManager` is now passed in the function as a regular reference, not as a `shared_ptr`. Besides that fact that passing this as `shared_ptr` is simply incorrect (because there is no ownership sharing/transferring here), we need this change because we cannot construct `shared_ptr` from `this` inside `UIManager` class (especially in the constructor).
Besides that:
* `const &` everything (correctness, explicit intention, performance);
* Names were unified with the rest of the code;
* `auto` everything;
* All JSI stuff is now explicitly prefixed with `jsi::`;
* `using` instead of `typedef` (modern C++ syntax);
* Lamdas instead of std::bind (same perfromance, much more clear and flexible);
Reviewed By: mdvacca
Differential Revision: D9835901
fbshipit-source-id: 935be0ae889fe5508ffa9498282c939c816587e1
Summary: In modern C++ `const` basically means `thread-safe` and we commit that all that methods are thread-safe.
Reviewed By: mdvacca
Differential Revision: D9836100
fbshipit-source-id: 4241ca80da77338b25246e622cf8d7e8c360eff7
Summary:
The spec says that `bridge_transfer` indicates that we "transfer ownership of the pointer" to ARC which implies that as soon this part of the code does not need the object, it will be deallocated. However, that's not what we want here. This object is actually already owned by another ARC-powered code somewhere else and the pointer to it was transferred as a raw pointer through the C++ world.
So, we want to keep the ownership of the object on the other side but still imply the lifetime of the object. So how can we do that? Simple, we have to use `bridge`.
Why? ARC is not magical, it's just automatic ref counting. And I think the only difference between `bridge` and `bridge_transfer` is how many refcounter's bumps will be added to the generated code. In the case of `bridge_transfer` it is zero, in the case of `bridge` it is one. So, initializing a new Objective-C variable that points to the shared resource we have to bump the counter once, so we have to use `bridge`.
Reviewed By: mdvacca
Differential Revision: D9819405
fbshipit-source-id: 9e7af343917ec4407a64d884402b10ee2a8097f9
Summary: We will need that to manage collections of attributed strings.
Reviewed By: mdvacca
Differential Revision: D9803351
fbshipit-source-id: 0ea9719f97ed30ff6dfe17b6dbebf448afe228b3
Summary: We will need this eventually.
Reviewed By: mdvacca
Differential Revision: D9799852
fbshipit-source-id: 0411e2f41540273c80f425e04c877fe51b9b2374
Summary:
I realized that instead of using shared_ptr's type-erasure feature, we can make the EventHandler's destructor virtual and this itself will allow safe deallocation by a pointer to a base class.
We cannot use the same technic for EventTarget thought because having a weak_ptr to this is another feature of shared_ptr that we need.
Reviewed By: mdvacca
Differential Revision: D9775742
fbshipit-source-id: 3c23a163827e8aa9ec731c89ce87051a93afe4ca
Summary: Instead of relying on explicit `RawEventDispatchable` function, we simply check the existence of the `weak_ptr` to `EventTarget`. This is efficient and sufficient because only an EventEmitter retains an associated EventTarget.
Reviewed By: mdvacca
Differential Revision: D9764858
fbshipit-source-id: 4ac25d925f189d0f8b9002e52388fd51629934a8
Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
Summary:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary: buildifier was updated and now we sort loads!
Reviewed By: zertosh
Differential Revision: D9771824
fbshipit-source-id: 0001aa5f656d4aa40b3498d5bfd792a3d14e56e1
Summary:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary:
When text nodes are nested, as below, `onPress` handlers need to be correctly invoked:
```
render() {
return (
<Text onPress={() => console.warn('hi')}>
hi
<Text onPress={() => console.warn('ramanpreet')}>ramanpreet</Text>
</Text>
);
}
```
In the above example, clicking on "hi" should warn "hi", and clicking on "ramanpreet" should warn "ramanpreet". This diff implements that behaviour.
Reviewed By: shergin
Differential Revision: D9696905
fbshipit-source-id: 2daf24e76c3b3c37aa36cd1540e54876a367faf7
Summary:
This diff includes two changes:
1. `TextShadowNode` represents virtual texts. For the time being, virtual text nodes only need touch capabilities so that they can handle `onPress` events for their children. Therefore, we should set the `TextShadowNode`'s `EventEmitterT` to `TouchEventEmitter`.
2. Since `ParagraphShadowNode` extends an instance of the `ConcreteViewShadowNode` template, it automatically uses the `ViewEventEmitter` if no event emitter is specified. I think it's better to make the event emitter explicitly specified. So, I've included that change in this diff.
Reviewed By: shergin
Differential Revision: D9696906
fbshipit-source-id: ac053ffdde4c2fbc6351f177c07a2ada4445cbb8