[pull] master from facebook:master#596
Merged
pull[bot] merged 7 commits intoAlan-love:masterfrom Dec 30, 2020
Merged
Conversation
…Module in Fabric Summary: This method refactors the preComputeConstantsForViewManager to avoid loading UIManagerModule when using Fabric + Static View configs changelog: [internal] internal Reviewed By: shergin Differential Revision: D25468182 fbshipit-source-id: e95b0e7d013e832792fb77fc0b6e5705d7f04868
Summary: Right now we assume in the Image component that any prop changes requires a redraw of the image, even if the props set are identical. Noop prop updates can be caused in Fabric by LayoutAnimations. This may go away in the future, but only when we have a new animations system. I don't think most other components need to be concerned with this, and many other components already guard against unnecessary redraws. Since the image "flashes" when it is loaded, unlike most other native components, this issue is more noticeable for images. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D25727482 fbshipit-source-id: 75ffa456bddc1208900733140ce4ff19f7e2c11e
…ew non-interpolated prop values at beginning of animation, not end Summary: In Android, only changed prop values are sent to the mounting layer via folly::dynamic maps. In the LayoutAnimation system, before this, we only sent that map at the /end/ of the animation for any non-interpolated values (for example, image source is not interpolated so it was not updated until the end of the animation). However, what we probably expect is that all non-interpolated values change immediately, and interpolated values smoothly transition. This diff makes that change on Android by using the final RawProps as the /initial/ value that interpolations are stacked on. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D25727483 fbshipit-source-id: e692d37b9965fedcdf429a81d60b7cb7f0c6abe1
…instead of the initial view Summary: To ensure that we're not sending old eventEmitters or State objects to the mounting layer, or potentially out-of-date Props objects, base animated interpolations on the final ShadowNode instead of the initial. Changelog: [Internal] Reviewed By: shergin Differential Revision: D25727481 fbshipit-source-id: 560ae8d25c7cec4c2137e70b4571b762f461edff
Summary: Remove temporary Litho-interop feature flag. Changelog: [Internal] Differential Revision: D25445364 fbshipit-source-id: c0fa3e6e5e55c0997e4a5ddd6c1cc5695878c7d2
Summary: Even though replacing an error with a warning does not look like a future-proof solution here are the reasons for this: * The measuring operation might just fail because of the async nature of React Native. And here, from my understanding, we don't even have a good reason for measuring. Auto-scrolling to selected textinput (which is the reason for this code, AFAIK) is a standard feature that OS does for all text input. I suspect that this (very old) feature was built in a timeframe where this system feature was originally broken (sometime before 2016). * This product-facing API does not have an error-callback, so just loggin an error here is as (not) actionable as logging a warning. * The error callback was never implemented in the pre-Fabric world, so it *never* got called for years, and now when Fabric is starting calling in some cases, it is being "punished" for this. In the next diff, I will try to retrofit this feature back to Paper to reach parity with Paper. Changelog: [Internal] Differential Revision: D25700156 fbshipit-source-id: 319a146b17cc2130848148ad11adbde16e86c5d5
Summary: Consolidate CocoaPods codegen scripts under a single `use_react_native_codegen!` method in `react_native_pods.rb`. This is the first step towards making the codegen scripts library-agnostic. There are still a handful of hardcoded assumptions in place (e.g. the output directory structure, the use of a separate directory for components), but with some work one would be able to add codegen support to arbitrary CocoaPods podspecs. The codegen script no longer takes a CODEGEN_PATH argument, and will instead attempt to use the local react-native-codegen package if available, and fallback to using the node_modules/react-native-codegen package if not. ## Usage The `use_react_native_codegen!` method has two arguments: - `spec`, a pod [Specification](https://www.rubydoc.info/github/CocoaPods/Core/Pod/Specification) object. - `options`, an optional object. Supported keys: - `:srcs_dir`, the path to your JavaScript sources. Your native module or component specs should be located somewhere in this directory. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D25728053 fbshipit-source-id: feec587b656d5b220598ce6196ea6bb34a9580a9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )