This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Summary: @public
Make the flow type of TimingAnimationConfig and TimingAnimation the same as SpringAnimationConfig and SpringAnimation.
This is a more accurate flow type as both are multiplexed through maybeVectorAnim().
Reviewed By: @sahrens
Differential Revision: D2410166
Summary: Importing JS changes to fbobjc which should be maintained as a source of truth
for React Native JS files. For more details about this change, please refer to
the original diff in fbandroid repo: D2410797
Reviewed By: @andreicoman11
Differential Revision: D2424679
Summary:
The CameraRoll-related APIs were mixed in with the Image classes due to legacy coupling issues. Now that the APIs have been decoupled, it makes more sense for the CameraRoll classes to live in a separate library.
This will be a breaking change for apps using the CameraRoll or related APIs. Fix is to add the RCTCameraRoll lib to your project.
Summary:
GIF images are currently loaded as a CAKeyframeAnimation, however returning this animation directly from RCTImageLoader was dangerous, as any code that expected a UIImage would crash.
This diff changes RCTGIFImageLoader to return a UIImage of the first frame, with the keyframe animation attached as an associated object. This way, code that is not expecting an animation will still work correctly.
Summary:
We currently wait until after views have been updated on the main thread before sending layout events. This means that any code that relies on those events to update the UI will lag the atual layout by at least one frame.
This changes the RCTUIManager to send the event immediately after layout has occured on the shadow thread. This noticably improves the respinsiveness of the layout example in UIExplorer, which now updates the dimension labels immediately instead of waiting until after the layout animation has completed.
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
Supports `onLayout` for Touchable*` by piping onLayout
through to the native component inside since only native components support
it by default.
Summary:
Now that UITextViews have a delegate, they consume the "tap to scroll to top" gesture. This diff restores the original behavior of letting the top-level scroll view (if any) scroll to top instead.
I tried exposing scrollsToTop as a prop and was semi-successful in that I could turn scroll-to-top on and off for the top-level scroll view scroll, but the text view itself would never scroll to top. So instead of exposing it as a prop, this diff sets scrollsToTop always to NO, which is how TextInput behaved previously.
Closes https://github.com/facebook/react-native/pull/2333
Github Author: James Ide <ide@jameside.com>
Summary:
1) Makes params more intuitive (only one now, bounciness, which maps intuitively to number of oscillations).
2) Satisfies boundary conditions (f(0) = 0, f(1) = 1) so animation actually goes where you tell it (before it would finish at a random location depending on the input params).
3) Simple test to verify boundary conditions.
Summary:
This will throw an error message with the problematic callback module/method. Previously we would get an invariant in this case when we try to access `callback.apply` later in the method.
Martin Konicek
Andrei Coman
Dorota Kapturkiewicz
Yamill Vallecillo
Nick Lockwood
Bill Fisher
Alex Kotliarskyi
Christopher Chedeau
Chace Liang
Nacho Lopez Sais
Spencer Ahrens
Gabe Levi
Aaron Chiu
Pieter De Baets
Alex Akers
Oliver (Cunpu) Bo
Hedger Wang
Marius Butuc
James Ide
Nathan Spaun
Felix Oghina
Eric Vicenti
Andy Street
