Summary: RCTShadowText currently overrides a couple methods from RCTShadowView to reset the count of the cssNode children to 0. This diff instead moves that logic into RCTShadowView behind a configurable flag making it easier to reason about.
Reviewed By: javache
Differential Revision: D3586434
fbshipit-source-id: 4389a8119dc49e3fc4357174c87c0c69287ae385
Summary: fillCSSNode was only ever used in RCTShadowView to set the child count which is already performed in insert/remove subview calls and in RCTShadowText is was used to set the measure function which can be done in the initializer instead.
Reviewed By: majak, javache
Differential Revision: D3586418
fbshipit-source-id: de2155daf0f1702c8977bf23183a3b6a650d016b
Summary:
WebView component detect phone numbers in html as URL links by default. But sometimes we don't want this behavior.
This PR add dataDetectorTypes as a prop of WebView, so one can specify value of this prop as one or more of phoneNumber/link/address/calendarEvent/none/all
This prop maps to UIWebView.dataDetectorTypes
Closes https://github.com/facebook/react-native/pull/8743
Differential Revision: D3556440
fbshipit-source-id: 55f01d2cdd785381f261a9dc931aa9311f0ad1d4
Summary: We deprecated it a while back and nobody is using it internally.
Reviewed By: majak
Differential Revision: D3542602
fbshipit-source-id: dfe11a47b21d2f8a7c946c902f0ea427615ffc31
Summary:
I used the reproducible steps as described in origin bug ticket #7987 as test plan.
This has the same contents as PR #8130 but then against master per janicduplessis request.
Closes https://github.com/facebook/react-native/pull/8134
Differential Revision: D3491126
fbshipit-source-id: a22669dc998f82b36fbe31d882d0a29f0912e2ee
Summary: This diff build the connection between the native code and js code so that the js could get IsRTL value and us ForceRTL function.
Reviewed By: fkgozali
Differential Revision: D3447013
fbshipit-source-id: 9f6c7f71cef0add7bd5beb0ba2b1543f0cabc2b3
Summary:
Issue we were seeing: scrollview would clip its cells when it was resized to 0 height and moved offscreen, but it wouldn't add it back when it was resized and moved back
Why this was happening: scrollview wouldn't rerun its un/clipping logic after the first run unless 1/it has 0x0 frame or 2/it has been scrolled. Neither was happening here.
Fix: run the un/clipping logic when scrollview's frame has been changed since the last clipping.
Reviewed By: javache
Differential Revision: D3436996
fbshipit-source-id: 1a8cfeb72b425fcc80815d30743fa308b9c75ab6
Summary: Converted the zIndex property on iOS to NSInteger instead of double. This is consistent with the CSS spec, and helps to simplify the Android implementation.
Reviewed By: javache
Differential Revision: D3411491
fbshipit-source-id: 902ebc29aac39a65f7e8707a28607655f9f5052c
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
The `removeClippedSubviews` feature works by umounting views from the hierarchy if they move outside the bounds of their parent.
This was previously restricted to clipping views which had `overflow: hidden`, since we cannot efficiently check whether the subviews of a view go outside its bounds, and so clipping a view that has potentially overflowing children becomes an expensive recursive operation.
The problem with this is that `overflow: visible` is the default, and it's not well documented nor easy to tell that `removeClippedSubviews` has been set up correctly (i.e. with all children having `overflow: hidden`).
When I checked, I found that `removeClippedSubviews` was not working on any of the examples in UIExplorer, nor in several of our internal apps, because the views inside the ListView has `overflow: visible`. This was probably caused by an infra change at some point, but I'm not sure how long it's been broken.
It's vanishingly unlikely that anyone would ever deliberately want subviews to overflow their bounds in this scenario, so I've updated the logic to simply ignore the `overflow` property and assume that views should be clipped if you are using the `removeClippedSubviews` property on the parent.
Cons / Breaking changes: in some rare circumstances, a view might get clipped prematurely if its parent is outside the scrollview bounds, but it itself is inside. This doesn't occur in practice in any of our products, and could be worked around with additional wrapper views if it did.
Pros: removeClippedSubviews is now much easier to use, and much more likely to work as intended, so most list-based apps should see a performance improvement.
Reviewed By: javache
Differential Revision: D3385316
fbshipit-source-id: 1c0064a4c21340a971ba80d794062a356ae6cfb3
Summary:
RCTScrollView was calling `dockClosestSectionHeader` in `reactBridgeDidFinishTransaction`, which triggers a layout update. The reason for this was in case the `stickyHeaderIndexes` property was updated, which would require the headers to be adjusted.
However, doing this in `reactBridgeDidFinishTransaction` had the affect of causing `layoutSubviews` to be called repeatedly every frame even if nothing had changed and the scrollview wasn't moving, which was especially expensive when combined with the `removeClippedSubviews` logic, that loops through every view to calculate if it needs to be clipped.
This fix moves the `dockClosestSectionHeader` call into `didUpdateProps`, and checks that the stickyHeaderIndexes have actually changed before calling it.
Reviewed By: javache
Differential Revision: D3387607
fbshipit-source-id: c71e00c6fac48337a63d7fee7c7c23e016acf24e
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
Hey,
I've created a PR a few weeks ago #7264. It got merged in and then I received some emails and got mentioned in a few issues that it doesn't use renderAsOriginal prop on selectedIcon. Instead the app would use tint color.
The problem can be seen here #7467.
I've now added a method in TabBarItem that sets selectedIcon to renderAsOriginal if the prop is set.
I added a "relay" icon to UIExplorer TabBarIOS example so you can see the item is now rendered in color as the image supplied.
Oh and also should this PR be made from master. Had to work on this issue from 0.27 because the master was broken for me.
Closes https://github.com/facebook/react-native/pull/7709
Differential Revision: D3339795
fbshipit-source-id: d8d4699bb617ecae8996a6627f3774c6473c19e0
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
The default itemPositioning is `automatic` (referred to `auto` in this pull request) - you can check its behaviour in the docs attached.
Sometimes that value has to be modified to have more predictable appearance as described in #4136.
Closes https://github.com/facebook/react-native/pull/7217
Differential Revision: D3220958
Pulled By: mkonicek
fbshipit-source-id: d4bf648b16e71825cd31c06d6b6396479767d19f
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary: Having UI modules access the shadowQueue via UIManager.methodQueue is fragile and leads to race conditions in startup, sometimes resulting in an error where the methodQueue is set twice, or not at all.
Reviewed By: javache
Differential Revision: D3304890
fbshipit-source-id: 7198d28314dbec798877fcaaf17ae017d50157e9
Summary:
There's an edge case in the `RefreshControl` which causes it to show as refreshing when the state is set to false. When the component is initialized with `refreshing` set to `true` on initial render but set to `false` before `layoutSubviews` is called, it will call `beginRefresh` and ignore its state. That's because `layoutSubviews` never checks if `_currentRefreshingState` is in fact still `true`, it merely assumes it is.
This is fixed by simply doing a check for `_currentRefreshingState` before entering `beginRefresh` from `layoutSubviews`.
Closes https://github.com/facebook/react-native/pull/7556
Differential Revision: D3300124
fbshipit-source-id: d1dce8612e2c03b1f14284d513803d00af4b5c8a
Summary: We are deprecating nativeScrollDelegate property in RCTScrollableProtocol in favor of a scrollListener api. To register/unregister from scroll events use the addScrollListener/removeScrollListener methods
Reviewed By: javache
Differential Revision: D3278218
fbshipit-source-id: 54373cae8e9f8efa7cdbd40c51bcf21d368acf75
Summary:
Previously we had an issue where we would clip visible views during an animation, like swiping back a VC.
The root cause was mismatch between a view's frame and what is visible on screen. This happens because during an animation the frame (and other properties) of the animated view has final values, even that it's not yet rendered at that position.
This diff fixes this issue by not looking for a clippingView above the react root view, since the animation for VC transitions happens at view higher above the root view.
Reviewed By: javache
Differential Revision: D3281655
fbshipit-source-id: 996b1a9f223c5b2274dd3d7c05b8936612af05ba
Summary:
When throttling scroll events with `scrollEventThrottle`, `onScroll`
is not guaranteed to be fired for the final scroll position
of the `ScrollView`. This can cause a component to render UI that
is consistent with the resting scroll position of the `ScrollView`.
This commit guarantees that an `onScroll` event will be fired for
the resting scroll position of the `ScrollView`.
**Test plan (required)**
Verified commit fixes a reduced repro. Also tested fix in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7366
Differential Revision: D3269303
Pulled By: javache
fb-gh-sync-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
fbshipit-source-id: f68ecb7e9c18d1ac255c6f872fb7eb4aadd07799
Summary:
Previously, the back swipe navigation gesture would be enabled when the navigation bar is shown and disabled when the navigation bar is hidden.
This change enables developers to control the back swipe gesture independently of the visibility of the navigation bar. An example use case would be that an app wants to render a custom navigation bar so it sets `navigationBarHidden` to true and it wants to enable the back swipe gesture so it sets `interactivePopGestureEnabled` to true.
**Test plan (required)**
- Created a test app to verify setting `interactivePopGestureEnabled` to `true` and `false` with the navigation bar both hidden and shown.
- Verified prop works in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7369
Differential Revision: D3269304
Pulled By: javache
fb-gh-sync-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
fbshipit-source-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
Summary:
Previously, if a module implemented `setBridge:` we assumed that it needs to be initialised on the main thread. This assumption was not really warranted however, and it was a barrier to deferring module initialization.
This diff tweaks the rules so that only modules that override `init` or `constantsToExport**` are assumed to require main thread initialization, and others can be created lazily when they are first used.
WARNING: this will be a breaking change to any 3rd party modules that are assuming `setBridge:` is called on the main thread. Those modules should be rewritten to move any code that requires the main thread into `init` or `constantsToExport` instead.
`**` We will also be examining whether `constantsToExport` can be done lazily, but for now any module that uses it will still be created eagerly when the bridge starts up.
Reviewed By: javache
Differential Revision: D3240682
fb-gh-sync-id: 48f309e3158bbccb52141032baf70def3e609371
fbshipit-source-id: 48f309e3158bbccb52141032baf70def3e609371
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
![simulator screen shot 27 apr 2016 21 58 40](https://cloud.githubusercontent.com/assets/12081272/14866402/e51c7120-0cc3-11e6-9570-097b686c160f.png)
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
![simulator screen shot 27 apr 2016 21 59 06](https://cloud.githubusercontent.com/assets/12081272/14866419/f77aa7e2-0cc3-11e6-8c90-33209009bc09.png)
Or change it to yellow for demonstrating purposes
![simulator screen shot 27 apr 2016 21 59 13](https://cloud.githubusercontent.com/assets/1208
Closes https://github.com/facebook/react-native/pull/7264
Differential Revision: D3240924
Pulled By: nicklockwood
fb-gh-sync-id: 14a0de28abd064756320b7a74f128c255caa6b12
fbshipit-source-id: 14a0de28abd064756320b7a74f128c255caa6b12
Summary:
transformMatrix only worked on iOS and there is an equivalent API that (mostly)
works cross platform.
decomposedMatrix could technically be passed on Android but it wasn't document and explicitly flagged as not working.
My goal is to deprecate both uses and then the only supported API is the `transform: [{ matrix: ... }]` form.
The only difference is that on Android the matrix gets decomposed.
Currently there is some special cased magic that renames transform -> transformMatrix or decomposedMatrix depending on platform.
https://github.com/facebook/react/blob/master/src/renderers/native/ReactNative/ReactNativeAttributePayload.js#L50
Therefore I'm adding an alias for both native platforms called just "transform".
Next I'll swap over the JS to always target the name "transform". The only difference is how the value is marshalled over the bridge in processTransform.
To do this, I have to clean up a few callers. Mostly that's just swapping to the new API.
For buildInterpolator this is a bit trickier but this fixes it for all our use cases (which is only the Navigator in AdsManager).
Reviewed By: vjeux
Differential Revision: D3239960
fb-gh-sync-id: 838edb6644c6cdd0716834f712042f226ff3136f
fbshipit-source-id: 838edb6644c6cdd0716834f712042f226ff3136f
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary: Creating a view instance just to get the default view size is quite expensive, and affects startup time for the bridge as it must be done on the main thread. I've removed these cases and simply hard-coded the sizes in the JS file. This will need to be updated if the view sizes ever change, but in practice that's very unlikely.
Reviewed By: javache
Differential Revision: D3218917
fb-gh-sync-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
fbshipit-source-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
Summary: fixed a case where MapView could crash due to a race condition
Differential Revision: D3207304
fb-gh-sync-id: a63918d160258d76fce5d56994100a63f4c5fb68
fbshipit-source-id: a63918d160258d76fce5d56994100a63f4c5fb68