Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
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:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
Summary:
This diff attempts to fix a number of iOS native animation bugs related to improper node invalidation and a race with view creation. The major issues were presented in #9120 as problems 3 and 3b, but I'll recap here:
The invalidation model we use is overly complicated and incomplete. The proper combination of `_needsUpdate` and `_hasUpdated` will result in nodes values being recomputed. However, we do not invalidate nodes in all the places we should, e.g. if we create a new view and attach it to an existing value node (see example in #9120). This diff chooses to remove the `_hasUpdated` flag, and simply relies on the `_needsUpdate` flag to mark a node as dirty.
We mark nodes as dirty when they are:
- created
- updated
- attached to new parents
- detached from old parents
- attached to a view
Calling `updateNodeIfNecessary` will, if necessary, compute all invalidated parent values before recomputing the node value. It will then apply the update, and mark the no
Closes https://github.com/facebook/react-native/pull/10663
Differential Revision: D4120301
Pulled By: mkonicek
fbshipit-source-id: e247afcb5d8c15999b8328c664b9f7e764d76a75
Summary:
Support static values (non-animated) in transform config like Android already does.
**Test plan**
Tested in UIExplorer native animated example by adding a transform with a static value and comparing with JS.
Closes https://github.com/facebook/react-native/pull/10664
Differential Revision: D4109515
fbshipit-source-id: 2d7de17d51d6df835c569fd45d2de8fc170bf928
Summary:
This adds support for the `transform` animated node. This brings feature parity with the iOS implementation and allows running the NativeAnimated UIExplorer example that was created with the iOS implementation on Android. This is based on some work by kmagiera in the exponent RN fork.
This also adds support for mixing static values with animated ones in the same transform as well which is not supported on iOS at the moment. It is also implemented in a way that rebuilds the transform matrix the same way as we build it in JS so it will be easy to remove some of the current limitations like forcing the transforms order and only supporting one of each type.
**Test plan (required)**
Tested with the NativeAnimated example on Android and iOS. Also tested mixing in static values in a transform (`[{ rotate: '45deg' }, { translateX: animatedValue }]`).
Closes https://github.com/facebook/react-native/pull/8839
Differential Revision: D3682143
fbshipit-source-id: 5e6fd4b0b8be6a76053f24a36d1785771690a6f8
Summary:
This diff addresses the issues raised by kmagiera in https://github.com/facebook/react-native/pull/7884. Transforms should be applied in the order they are defined, just like in `processTransform.js`. A scale applied before a translation, for instance, should give a different result than a translation applied before a scale.
We leverage CATransform3D to do the heavy lifting. A concatenated transform is passed all the way to `RCTViewPropertyMapper`. It is compared with the transform currently applied to the view, and if different, applied. The same approach is used for opacity.
I think it makes the most sense to do this diffing in `RCTViewPropertyMapper`, as opposed to creating and cleaning up an `_updatedPropsDictionary` each frame in `RCTTransformAnimatedNode` and `RCTStyleAnimatedNode`. The node should keep its full value; applying a minimal set of altered props is an optimization. The higher up this optimization is implemented, the more assumptions it makes. e.g. that there will only ever be a sing
Closes https://github.com/facebook/react-native/pull/9050
Differential Revision: D3658139
fbshipit-source-id: ad6286762ef734084cbdf83c9bd9241190302d34
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Reviewed By: javache
Differential Revision: D3409179
Pulled By: nicklockwood
fbshipit-source-id: ef2d8840032e0c32f49e4a16ba86d448662e1751
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Differential Revision: D3401811
Pulled By: nicklockwood
fbshipit-source-id: 709e533243130153febef03ddd60d39e9fe70e3e
Summary:
Currently on iOS animations are being performed on the JS thread. This ports animations over to the native thread and performs them natively. A lot of this work has already been done on Android, but this PR enables a few animation nodes that Android doesn't yet support such as Transform, Multiplication, and Addition nodes.
Also there is a demo of the native animations added to the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/7884
Differential Revision: D3401811
Pulled By: nicklockwood
fbshipit-source-id: c8d750b75e4410923e17eaeb6dcaf079a09942e2
Anatolii Shevchenko
James Treanor
Héctor Ramos
Sophie Alpert
Janic Duplessis
Ryan Gomba
Brandon Withrow