Summary:
It's very important in complex UIs to be able to apply alpha channel-based masks to arbitrary content. Common use cases include adding gradient masks at the top or bottom of scroll views, creating masked text effects, feathering images, and generally just masking views while still allowing transparency of those views.
The original motivation for creating this component stemmed from work on `react-navigation`. As I tried to mimic behavior in the native iOS header, I needed to be able to achieve the effect pictured here (this is a screenshot from a native iOS application):
In this image, there are two masks:
- A mask on the back button chevron
- A gradient mask on the right button
In addition, the underlying view in the navigation bar is intended to be a UIBlurView. Thus, alpha masking is the only way to achieve this effect.
Behind the scenes, the `maskView` property on `UIView` is used. This is a shortcut to setting the mask on the CALayer directly.
This gives us the ability to mask any view with any other view. While building this component (and testing in the context of an Expo app), I was able to use a `GLView` (a view that renders an OpenGL context) to mask a `Video` component!
I chose to implement this only on iOS right now, as the Android implementation is a) significantly more complicated and b) will most likely not be as performant (especially when trying to mask more complex views).
Review the `<MaskedViewIOS>` section in the RNTester app, observe that views are masked appropriately.
Closes https://github.com/facebook/react-native/pull/14898
Differential Revision: D5398721
Pulled By: javache
fbshipit-source-id: 343af874e2d664541aca1fefe922cf7d82aea701
Summary:
Just a little typo fixing and wording clean up around some header docs.
Closes https://github.com/facebook/react-native/pull/14947
Differential Revision: D5398609
Pulled By: javache
fbshipit-source-id: 3eb40ef3308130c1d28b2efc7bb64d493e98825b
Summary:
**Motivation**
This is a re-worked version of #14260, by shergin's suggestion.
For iOS, if you want to inherit from a native ViewManagers, your custom ViewManager will not automatically export the parents' props. So the only way to do this today, is to basically copy/paste the parent ViewManager-file, and add your own custom logic.
With this PR, this is made more extensible by exporting the `baseModuleName` (i.e. the iOS `superclass` of the ViewManager), and then using that value to re-establish the inheritance relationship in `requireNativeComponent`.
**Test plan**
I've run this with a test project, and it works fine there. But needs more testing.
Opened this PR as [per shergin's suggestion](https://github.com/facebook/react-native/pull/10946#issuecomment-311860545) though, so we can discuss approach.
**Discussion**
* Android already supports inheritance, so this change should be compatible with that. But, not every prop available on `UIManager.RCTView.NativeProps` is actually exported by every ViewManager. So should `UIManager.RCTView.NativeProps` still be merged with `viewConfig.NativeProps`, even if the individual ViewManager does not export/use them to begin with?
* Does this break other platforms? [UWP](https://github.com/Microsoft/react-native-windows)?
Closes https://github.com/facebook/react-native/pull/14775
Differential Revision: D5392953
Pulled By: shergin
fbshipit-source-id: 5212da616acfba50cc285e2997d183cf8b2cd09f
Summary:
Fixed the test script to properly setup our third-party deps and tweaked the third-party specs a bit so they work correctly.
This currently works for projects using static libraries, but fails when using dynamic libraries (`--use-libraries`)
cc mhorowitz alloy
Closes https://github.com/facebook/react-native/pull/14100
Differential Revision: D5380728
Pulled By: javache
fbshipit-source-id: e78b6bd4466ebf2bf30b7e361eff10ec14b36a55
Summary:
This diff fixes a possibly inconsistent state of view hierarchy caused by async delayed deleting manipulation on UIView's tree.
Even if new approach may seem tricky, the previous one was just terribly wrong.
Reviewed By: javache
Differential Revision: D5374670
fbshipit-source-id: 36f27330aa8b0e4e00fe43739afe3bc6a8602e30
Summary:
* Cleanup some header files so we use more forward declarations
* Rename Executor to JSExecutor.h
* Move some typedefs to more appropriate locations
Reviewed By: mhorowitz
Differential Revision: D5301913
fbshipit-source-id: e75154797eb3f531d2f42a5e95409f4062b85f91
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
The problem occurs when a ScrollView's content height is smaller than the ScrollView height. If the method `scrollToEnd` is called on the ScrollView, it will pull the content down until the bottom of the content is aligned with the bottom of the Scrollview container.
This fix will ensure the proper functionality: That the furthest the ScrollView can scroll down is to where the top of the content container is at the origin (i.e., the ScrollView scroll number cannot be less than 0).
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
I tested on a scenario where the ScrollView is almost the full size of the screen, and the content of the ScrollView has a height of much less. In this situation, the `scrollToEnd` method was executed and the content stayed in the same position. This is the intended behavior. If the content of the ScrollView is smaller than the height of the ScrollView, then the `scrollToEnd` method should not scroll anywhere.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12889
Reviewed By: javache
Differential Revision: D5289894
Pulled By: sahrens
fbshipit-source-id: df2e779ee855c1dea85d33649d754371ad244bca
Summary:
Apple TV compilation is currently broken in master -- this fixes it.
Existing tests will pass after this change.
Closes https://github.com/facebook/react-native/pull/14652
Differential Revision: D5295021
Pulled By: javache
fbshipit-source-id: 8b4b0db0afa1caeacac0ad01abbed80fa7e39738
Summary:
Fix this crash by making sure the RCTDeviceInfo is doing things on the main thread.
This fixes#14043.
Reviewed By: ashwinb
Differential Revision: D5286746
fbshipit-source-id: cce3426a6e7e7221cff82f8bca663d9a060dd358
Summary:
Yes, `display: none;` did not work on iOS before this commit.
Now it "just works". It can be useful when some view needs to be hidden temporary and efficiently.
Reviewed By: javache
Differential Revision: D5173936
fbshipit-source-id: 83a03fff04dd3a872d7dd6bf673189f932906776
Summary:
That's interesting!
If we apply `display: none;` style to some node, Yoga will stop calculation layout for this subtree (which is reasonable).
So, from RN perspective we have to stop applying layout for hidden subtree because it is meaningless and causes another errors.
Note: We do actually not support `display: none;` yet. It stops computing layout, but it does not hide the views!
Reviewed By: javache
Differential Revision: D5168651
fbshipit-source-id: 29a9385c76a0f9d637285fc0d268ccc39879ca0a
Summary:
Override `canHaveSubviews` in RCTShadowView subclass to disallow any nested content.
For now, this prop will be checked only in DEV mode for performance reasons.
Reviewed By: javache
Differential Revision: D5189083
fbshipit-source-id: 87087dd806e1fd7320128dab969b13642174f81c
Summary:
C++ doesn't provide an implicit cast to an enum value from the enum's backing type. When a `.mm` file calls `RCT_ENUM_CONVERTER`, we end up with the following compiler error:
> Error: cannot initialize return object of type `<TypeName>` with an rvalue of type `NSInteger`
Since `RCT_ENUM_CONVERTER` is a macro, this error will appear whenever we try to expand the macro in a C++ context.
The project compiles and runs as expected when this additional cast is added 😃
Closes https://github.com/facebook/react-native/pull/14408
Reviewed By: javache
Differential Revision: D5215584
Pulled By: jballer
fbshipit-source-id: 7f4464afd7cd9dc9a014f646278bae20731f08ba
Summary: Optimize ScrollView by adding flag "DEPRECATED_sendUpdatedChildFrames" to gate whether updatedChildFrames data is computed and propagated on scroll events. The frame data is used in ListView by the onChangeVisibleRows prop. When this prop is not defined, unnecessary computation in ScrollView should not be performed.
Reviewed By: sahrens
Differential Revision: D5174898
fbshipit-source-id: e3eaed8760b76becf14dfeb00122bdebdaeae4ef
Summary:
Flashing scroll indicators is a standard behavior on iOS to show the user there's more content.
Launch RNTester on iOS, go to the ScrollView section, tap the "Flash scroll indicators" button.
You'll see this:
I've exposed the method `flashScrollIndicators` on all scrolling components that were already exposing a `scrollToXXX` method so it's usable from those components using a ref.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/14058
Differential Revision: D5103239
Pulled By: shergin
fbshipit-source-id: caad8474fbe475065418d771b17e4ea9766ffcdc
Summary:
Sometimes, when we implement some custom RN view, we have to proxy all accessible atributes directly to some subview which actually has accesible content. So, in other words, this allows bypass some axillary views in terms of accessibility.
Concreate example which this approach supposed to fix:
https://github.com/facebook/react-native/pull/14200/files#diff-e5f6b1386b7ba07fd887bca11ec828a4R208
Reviewed By: mmmulani
Differential Revision: D5143860
fbshipit-source-id: 6d7ce747f28e5a31d32c925b8ad8fd4b98ce1de1
Summary:
Our iOS devs frequently turn off wifi and forget to turn it back on. This message should remind them that they need wifi to connect. Often they waste several minutes due to this problem.
I'm not sure if there's a test plan to apply here. Any suggestions?
Closes https://github.com/facebook/react-native/pull/13551
Differential Revision: D5149231
Pulled By: hramos
fbshipit-source-id: 0afc71024f10f802ac1a50435fb57fc10a02c819
Summary:
This change introduces some APIs that are useful for making announcements through the screen reader on iOS:
- `announceForAccessibility`: The screen reader announces the string that is passed in.
- `announcementFinished`: An event that fires when the screen reader has finished making an announcement.
You can already solve similar problems with RN Android using the `accessibilityLiveRegion` prop. Live regions are a different feature but they can be used to solve the same problem. This commit does not attempt to add live region support in RN iOS because Apple did not build live region support into iOS.
Verified that `announceForAccessibility` causes VoiceOver to announce the string when VoiceOver is enabled. Verified that `announcementFinished` fires with the appropriate data in the event object. Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14168
Differential Revision: D5137004
Pulled By: javache
fbshipit-source-id: b3c10f3dfc716430a16fcc98e1bb6fe52cabd6a5
Summary:
Motivation:
* We maintain two different implementation of <TextInput> (multilined and singlelined), this change makes the implementations much similar which will help us to support and improve both of them in the (near) future;
* We have to have separated RCTView-based container view for (TextField) to support sofisticated bordering and so on;
* It opens to us possibility to unify UITextView and UITextField subclasses and remove code duplication across RCTTextView and RCTTextField;
* Making things decoupled in general will allow us to fix existing bugs with events.
Reviewed By: mmmulani
Differential Revision: D5083010
fbshipit-source-id: 2f2d42c2244d2b39256c51480c1f16f4e3947c01
Summary: Previosly `borderWidth` did not affect actual content inset (which was a problem).
Reviewed By: mmmulani
Differential Revision: D5072483
fbshipit-source-id: d43cba7414a9335b9f9fd4d1565d7aee403cce0e
Summary:
This avoids reordering views because it created some bugs when the native hierarchy is different from the shadow views. This leverages `layer.zPosition` and takes z-index in consideration when we check what view should be the target of a touch.
**Test plan**
Tested that this fixes some layout issues that occurred when using sticky headers in the Expo home screen.
Closes https://github.com/facebook/react-native/pull/14011
Differential Revision: D5108437
Pulled By: shergin
fbshipit-source-id: 0abfe85666e9d236a190e6f54cdd5453cacfbcac
Adam Miskiewicz
Valentin Shergin
Eli Perkins
Christian Brevik
Nurzhan Bakibayev
Pieter De Baets
Pieter De Baets
Alex Dvornikov
Mehdi Mulani
Nathaniel Rankin Webb
dlowder-salesforce
Hank Brekke
Yu Wang
Jonathan Ballerano
Marc Horowitz
Viacheslav Radchenko
Ben Nham
John O'Leary
Theo Yaung
Jean Regisser
Dan Caspi
adamjmcgrath
Stephen Bird
Adam Comella
Janic Duplessis
