Summary:
@public
After reading about move-semantic and rvalue refs I realized that we (I) definitely overuse `auto &&` (aka universal reference) construction. Even if this is harmless, does not look good and idiomatic.
Whenever I used that from a semantical point of view I always meant "I need an alias for this" which is actually "read-only reference" which is `const auto &`.
This is also fit good to our policy where "everything is const (immutable) by default".
Hence I change that to how it should be.
Reviewed By: fkgozali
Differential Revision: D8475637
fbshipit-source-id: 0a691ededa0e798db8ffa053bff0f400913ab7b8
Summary:
@public
`ContextContainer` is general purpose DI container for Fabric.
We need this to communicate some enviroment-specific and/or platform-specific modules down to cross-platform C++ code.
The first one will be ImageManager. Soon.
Reviewed By: fkgozali
Differential Revision: D8475636
fbshipit-source-id: 0afc65063f818d0bab736cd2c55c6fdd21b629ac
Summary:
@public
... and we initalize this in Surface.
We need this for requesting images with proper size/pixel-density, setup proper parameters for rasterizing CALayer's and rounding layout metric values.
Then we have to figure out how to wire this up with YGConfig.
Reviewed By: fkgozali
Differential Revision: D8475639
fbshipit-source-id: cec7af581b94efb4595dcf3f232252ce87a1fde3
Summary:
@public
Added a property `accessibilityIgnoresInvertColors (boolean)` to Views which allows the Apple API `accessibilityIgnoresInvertColors` to be used in React Native.
Now, when a user has Display: Smart Invert enabled, you can set the property to be true, and things like photos and views with the property set to true will no longer be inverted when Smart Invert is enabled.
This property can also be applied to the Image Component.
Example Use Case:
```
<Image accessibilityIgnoresInvertColors={true} />
```
```
<View accessibilityIgnoresInvertColors={true} />
```
| Before | After |
| ------ | ----- |
|  | 
Reviewed By: PeteTheHeat
Differential Revision: D8549084
fbshipit-source-id: 82a3bc73c9e6d75d6b50ba013b88127f07692641
Summary:
@public
A few people have been complaining, including me, that when we compile a react native project, there are a lot of warnings from xcode, suggesting to update the project build settings to the new recommendations.
I took the liberty to actually update the xcode projects, so we can finally have these gone, as well as replace some deprecated methods with the new suggested ones.
[IOS] [MINOR] [Xcode] - updated the Xcode projects with the latest suggestions from Xcode 9.3, and replaced a few deprecated methods of iOS with their new replacements.
Closes https://github.com/facebook/react-native/pull/19574
Reviewed By: shergin
Differential Revision: D8530135
Pulled By: hramos
fbshipit-source-id: b9c9ede0e07760cb2207caa6b468bd5c241848dc
Summary:
@public
When JS first starts up, Fabric surface end up double registering itself, causing events to not work. So let's guard it so that registration happens only on reload case.
Reviewed By: shergin
Differential Revision: D8521002
fbshipit-source-id: 441f121786e860dc10e959e940b411c2afaf96dc
Summary:
@public
The bridge may send the reload event twice when reloading JS in some rare condition. The 2nd one was actually when the "new" bridge wasn't valid yet, so log an error if that happens. This may happen if the connection to Metro server gets into a weird state. Restarting Metro would solve the problem.
The issue was that `RCTBridgeWillReloadNotification` fired twice for each reload with metro connected.
Reviewed By: mmmulani
Differential Revision: D8509448
fbshipit-source-id: 647fb98c0a97503409a10451b8f152145947ae20
Summary:
A few people have been complaining, including me, that when we compile a react native project, there are a lot of warnings from xcode, suggesting to update the project build settings to the new recommendations.
I took the liberty to actually update the xcode projects, so we can finally have these gone, as well as replace some deprecated methods with the new suggested ones.
I made two react native projects, one with the regular react native and the other one using this branch.
Left is before, right is after:
[IOS] [MINOR] [Xcode] - updated the Xcode projects with the latest suggestions from Xcode 9.3, and replaced a few deprecated methods of iOS with their new replacements.
Closes https://github.com/facebook/react-native/pull/19574
Differential Revision: D8489006
Pulled By: hramos
fbshipit-source-id: 2922b2e76aca6883c4f5d04e9c511b9fc1029583
Summary:
Given async nature of RN, it is quite possible situation, hence it should not be a redbox.
And in Fabric it happends all the time which makes debugging painful.
Reviewed By: mdvacca
Differential Revision: D8473511
fbshipit-source-id: cfe7a1d3d105fde3b23db4c4c07b99864215c94c
Summary: After moving all matrix math to C++, the actual client native code is quite trivial.
Reviewed By: fkgozali
Differential Revision: D8344059
fbshipit-source-id: 6910c6af5de64d5f901e82075d30edbde177af40
Summary:
This is quite interesting.
In Fabric, on C++ layer we store `color` values as `SharedColor` objects which (on iOS) are `shared_ptr`s with custom deallocater (which calls CoreFramework's `CFRelease` function). All this means that we cannot directly transfer ovenership of this managed pointer to ARC (honestly, I am not 100% sure about that, but at least this "shared ownershipt between ARC and non-ARC worlds" concept is as dangerous as any "relying on implementation details" approach). To to so, we have to create a copy and transfer ownership of the copy to ARC (which we do in 1RCTCGColorRefFromSharedColor`).
Reviewed By: fkgozali
Differential Revision: D8344061
fbshipit-source-id: 8b6764e1539b1982b41f502bbd3307c7b6900fd9
Summary:
Trivial.
`nativeId` is meant to be used by subclasses of external inspector-like tools, so it does not have any real functionality.
Reviewed By: fkgozali
Differential Revision: D8344064
fbshipit-source-id: d86ef378cda1f7f0e9a7b4ffc09f51004ae530d2
Summary:
This is pretty straightforward implementation uses native `UISwitch`.
Suddenly we need Switch to test a bunch of other things.
Reviewed By: fkgozali
Differential Revision: D8344055
fbshipit-source-id: cfc51b8bc11198eb9d4d5e4745b96fb3a7f14de1
Summary:
This is just the convenient way to embed native views inside custom View components.
See coming <Switch> implementation as an example.
Reviewed By: fkgozali
Differential Revision: D8344056
fbshipit-source-id: 7f5f8cfeeffa7676bc7b562aa07f006cb9006575
Summary:
On JS reload the FabricUIManager and EventDispatcher didn't get release due to a retain cycle. This breaks the cycle.
In addition, force release the Scheduler on reload so that the stale classes get cleaned up properly, avoiding crashes. Also the surface now remounts the content correctly
Reviewed By: shergin
Differential Revision: D8414916
fbshipit-source-id: 4b14031f29b3bc9987d7aa765dc0d930a7de2b1e
Summary: Calling the event emitters on the main thread seems to be problematic, so let's dispatch it via the JS thread. This requires some changes to make "eventTarget" single-use because otherwise the binding would need to synchronize the actual JS call with the act of releasing the target.
Reviewed By: shergin
Differential Revision: D8375291
fbshipit-source-id: bd2b42731176ae209f4a19c232309c163fb1c01b
Summary: The app needs to find the surface by rootTag at some point.
Reviewed By: shergin
Differential Revision: D8391957
fbshipit-source-id: b0bb107b7be882071890afb46de17b50e7ee060d
Summary:
Using `EventHandlers` name was a bad idea, and I cannot tolerate it anymore.
The worst part of it is that when you have a collection of `EventHandlers` objects you cannot use plural word to describe it because `EventHandlers` is an already plural word.
And, this object is actually an event emitter, the thing on which we call events.
Reviewed By: fkgozali
Differential Revision: D8247723
fbshipit-source-id: b3303a4b9529bd6d32bb8ca0378287ebefaedda8
Summary:
RCTSurfaceTouchHandler is a complete rewrite of RCTTouchHandler which uses direct Fabric-specific event dispatching pipeline and several new approaches to managing active events (such as high-performant C++ collections, better management of identifier pool, and so on).
Besides that, the new implementation is much more W3C compliant that it used to be (see old TODOs near `receiveTouches()` implementation in Javascript).
So, touch events work now!
Reviewed By: fkgozali
Differential Revision: D8246713
fbshipit-source-id: 218dc15cd8f982237de7e2497ff36a7bfe6d37cc
Summary:
This is the thing which is handled in https://github.com/orta/cocoapods-fix-react-native today.
89a78ad349/lib/cocoapods-fix-react-native/versions/0_55_3-post.rb (L140-L164)
This should be the correct fix for #17799.
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Integrating React Native into an existing iOS project using CocoaPods without `DevSupport` subspec and seeing if the project successfully compiles.
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[IOS] [BUGFIX] [DevSupport] - Fix CocoaPods integration without DevSupport subspec
Closes https://github.com/facebook/react-native/pull/19265
Differential Revision: D8149786
Pulled By: hramos
fbshipit-source-id: c665e463b76aacdfb2022e82e36eb381d2d9ff2b
Summary: Note: Some features are not suported yet, e.g. event throttling.
Reviewed By: fkgozali
Differential Revision: D8082771
fbshipit-source-id: d60f6e9011283aeee7aff77dc9178e99f06deb5c
Summary: This also illustrates how we should use EventHandlers objects.
Reviewed By: fkgozali
Differential Revision: D8053357
fbshipit-source-id: cba084c8a871e40c7536720fce290c3467d33061
Summary:
Pretty trivial; new type of mount item & new method in the component protocol.
The default implementation in `UIView+ComponentViewProtocol` does nothing.
Reviewed By: fkgozali
Differential Revision: D8053355
fbshipit-source-id: a0418edf17ca75c4b94942b04acd93f3ea5d27e0
Summary: Moving target deployment to iOS 9.0+ from now on, removing customization for iOS 8.
Reviewed By: shergin
Differential Revision: D8053439
fbshipit-source-id: 292c58f15c6e6caf8b28d15c1521812d6ed675c5
Summary: Note: not all scrollview props and features (especially event listeners and imperative calls) are supported yet.
Reviewed By: fkgozali
Differential Revision: D7961868
fbshipit-source-id: 5277674fe976e089fd963066f78e705ad846d78d
Summary:
This diff contains several tight to each other changes (which can/should not be split into several diffs):
* The props parsing/conversion process was de-virtualized: we don't use virtual `apply` method to parse props anymore. Instead, we use old-fashioned constructors.
* All fields of Props classes which represent props values were marked as `const` which make impossible to modify them after the objects were created (even if we have non-const value-of/pointer-to the whole Props object). Those fields are also `public` now.
* All custom handwritten getters were removed (because we don't need them anymore).
So, now we don't need all those custom getters which makes code much more compact, performant and codegen-friendly.
Reviewed By: fkgozali
Differential Revision: D7901245
fbshipit-source-id: 9f4b1fd2da64bf963b63215ed3bd74b9d3c58dd5
Summary:
This diff deprecates `-[RCTSurface rootViewTag]` in favour of `-[RCTSurface rootTag]` which returns
same value but represented as `ReactTag` (`long`) instead of `NSNumber *`.
Reviewed By: mdvacca
Differential Revision: D7857044
fbshipit-source-id: f5427c30d3de2d3563e830f2caac70b7dc9631f9
Summary: Quite trivial but still very cool recycling of native view instances is finnally here, in React Native. �
Reviewed By: mdvacca
Differential Revision: D7804085
fbshipit-source-id: 644804da3185f9ed3fdea42d4d76c93e86934448
