Summary:
Add an example for Pager built with NavigationTransitioner & Animated.View
This example demostrates how to apply pre-defined gesture handling and
animation styles to the <Animated.View /> to build a Pager navigator.
Reviewed By: ericvicenti
Differential Revision: D3495807
fbshipit-source-id: 08e275010888925bc9fd1840e7052f975c95ad63
Summary: Add support inlining images into text inputs. For now this is only available on Android.
Reviewed By: andreicoman11
Differential Revision: D3470805
fbshipit-source-id: 14db05ec4d5af549bf314b903654314f39bf73ea
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
This adds support for a text field that the user can click-and-drag to select text (which can then be copied using the native selected-text-hover-widget).
I'd love to add this to iOS too, but iOS appears to draw glyphs directly to the screen for its <Text> widget (versus using UITextField), so it might be too difficult to support there. But at least I can support my Android users with this change.
Let me know if/what kind of "demonstrate the code is solid" you would like for this. A screenshot of selected text with this property set?
Closes https://github.com/facebook/react-native/pull/8028
Differential Revision: D3474196
Pulled By: bestander
fbshipit-source-id: 8d3656681265a0e6229bfa13ff2ae021e894d3cd
Summary:
This adds a new resize mode for iOS 'repeat' that tiles the image over it's frame. This allow to easily create a view with a repeating background pattern which there is no way to do at the moment without including a bunch of different sized assets.
I'm not 100% sure it should be a resizeMode or a separate prop but I went with resizeMode since it made more sense to me and the are not really any use cases where we'd want to use this with another resizeMode other than 'stretch'.
**Test plan**
Tested mainly by adding a UIExplorer example, also tested that changing the resizeMode prop from and to 'repeat' worked properly.
I'd like to implement this on Android too but it is a bit trickier since Fresco's ImageView doesn't support image tiling and would require submitting a PR there too :(
Closes https://github.com/facebook/react-native/pull/7968
Differential Revision: D3469119
Pulled By: javache
fbshipit-source-id: ab9dbfe448a5b0771dbf0c41fcceeb366210f583
Summary:
Add an example for <NavigationTransitioner /> that shows how to use
<NavigationTransitioner /> and <Animated.View /> to build a stack of
animated scenes that render the navigation state.
This also defines the generic method for NavigationTransitioner to render scenes.
Reviewed By: ericvicenti
Differential Revision: D3422322
fbshipit-source-id: b9ff4c5102442a110739a546565552496349d473
Summary:
This diff translates implementation of transform matrix decomposition from JS to java. This is to support offloading animations of transform property, in which case it is required that we can calculate decomposed transform in the UI thread.
Since the matrix decomposition code is not being used for other platform I went ahead and deleted parts that are no longer being used.
**Test plan**
Run UIExplorer Transform example before and after - compare the results
Closes https://github.com/facebook/react-native/pull/7916
Reviewed By: ritzau
Differential Revision: D3398393
Pulled By: astreet
fbshipit-source-id: 9881c3f565e2050e415849b0f76a0cefe11c6afb
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
UIExplorerActivity.java and MoviesActivity.java should override `getReactNativeHost` method. And this PR will fix https://github.com/facebook/react-native/issues/8215.
**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.
**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/8223
Differential Revision: D3456957
fbshipit-source-id: cc0b51e5bfaec71d210bfba81b1f7cd06a723d8c
Summary:
This moves into open source the PermissionsModule and the activity and listener interfaces
necessary to make permissions work.
It also moves the PermissionsExample into the UIExplorer. In order to make this
work, the device has to be Android M and above, and the target sdk of the app has to be 23+, so I changed the uiexplorer manifest to
target that API. This has the unfortunate consequence that people testing on
devices with API 23+ will have to enable the `draw over other apps` setting that
react needs for RedBoxing. The app will automatically send the user to that screen,
so enabling the setting and resuming the app should be trivial.
For testing, try requesting permission for a permission that is currently
revoked. If a permission is granted, it can be revoked via adb (`adb shell pm
revoke com.your.app android.permission.PERMISSION_NAME`), and then requested.
Reviewed By: bestander
Differential Revision: D3431324
fbshipit-source-id: 8cbaea676d2b5727cb5191cdb77a02e213bf9ba3
Summary:
This replaces ActivityIndicatorIOS and indeterminate ProgressBar that were deprecated recently with ActivityIndicator across the codebase and examples and a few other cleanups.
This also make a small tweak to ActivityIndicator so it uses the Android theme color instead of gray when no color is specified.
Use Slider instead of SliderIOS in CameraRoll example.
Remove the line about unifying ActivityIndicator and ProgressBar.
**Test plan**
Tested the affected components in UIExplorer on iOS and Android, tested the changes made in Movies example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/8082
Differential Revision: D3429770
fbshipit-source-id: 3b2e1196a8b9fe00d47a7aa1bbc079b094796421
Summary:
This adds support for specifying multiple sources for an image component, so that native can choose the best one based on the flexbox-computed size of the image.
The API is as follows: the image component receives in the `source` prop an array of objects of the type `{uri, width, height}`. On the native side, the native component will wait for the layout pass to receive the width and height of the image, and then parse the array to find the best fitting one. For now, this does not support local resources, but it will be added soon.
To see how this works and play with it, there's an example called `MultipleSourcesExample` under `ImageExample` In UIExplorer.
Reviewed By: foghina
Differential Revision: D3364550
fbshipit-source-id: 66c5aeb2794f2ffeff8da39a9c0b95155fb2d41f
Summary:
Remove prop `onNavigate` from these views.
- NavigationAnimatedView
- NavigationCardStack
- NavigationCard
Also, the `sceneProps` onject that is passed to the `renderScene` function
no longer contains `onNavigate`.
The contract that `onNavigate` expects has been vague. Different data flow
system may expect complete different params for such function
For instance,
* onNavigate({type: 'back'});
* onNavigate({type: 'BACK'});
* onNavigate('back'});
We have no intention to unify such generic API since it's more likely to be
constrained by the data flow frameworks such as redux or flux.
Also, passing the prop `onNavigate` all the way down to the component that
invokes the navigation action can be really tedious. We'd expect developer
to either pass such callback (onNavigate) via context or just set up some
kind of static actions that any component can call directly.
`onNavigate` was previously added as a part of (redux-like) reducers-friendly
feature but that's no longer the case.
This new prop `onNavigateBack` is used to explicitly handle the case when the back button or back gesture
is performed.
Reviewed By: ericvicenti
Differential Revision: D3410873
fbshipit-source-id: a703cf0debd474cff33d6610e858b9c4bb3ecbf5
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:
== API Breaking Change ==
- Add unit tests to ensure that NavigationStateUtils does the right thing.
- Remove the logics that lets NavigationStateUtils accept empty value as input
and return a new state.
- Remove the method `NavigationStateUtils.getParent`, `NavigationStateUtils.set`. These methods are rarely used and they can be replaced by other methods.
Reviewed By: ericvicenti
Differential Revision: D3374934
fbshipit-source-id: 0fdf538d014d7c5b4aa1f15a0ee8db9dc91e33cd
Summary:
For navigation actions at high level, reducers from NavigationReducers does not
know anything about the app-specific state thus people won't use these reducers.
Instead, people should build their own reducers.
There are a lot of good libraries available that help people to reducing things if that's
what they really need.
At the low level, for navigation state changes that don't involve app-specific state,
`NavigationStateUtils` should server that kind of need.
`NavigationReducers` serves little benefit cause it does not know the app state, it does
not know how to traverse the navigation states which can be a tree, a list or a map.
That said, we hold no interest in owning in the core navigation library.
Reviewed By: ericvicenti
Differential Revision: D3372910
fbshipit-source-id: 797382b46e7d64b7ad578b51dd37e2b941faa83d
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
Summary:
KeyboardAvoidingView is a component we built internally to solve the common problem of views that need to move out of the way of the virtual keyboard.
KeyboardAvoidingView can automatically adjust either its position or bottom padding based on the position of the keyboard.
Reviewed By: javache
Differential Revision: D3398238
fbshipit-source-id: 493f2d2dec76667996250c011a1c5b7a14f245eb
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:
When using FormData upload images or files, in Android version, network module cannot send an event for showing progress.
This PR will solve this issue.
I changed example in XHRExample for Android, you can see uploading progress in warning yellow bar.
Closes https://github.com/facebook/react-native/pull/7256
Differential Revision: D3390087
fbshipit-source-id: 7f3e53c80072fff397afd6f5fe17bf0f2ecd83b2
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
The recent and upcoming API refactoring works makes maintaining
the examples harder and harder.
This removes the old examples that use too much deprecated APIs such as
Reducers, Animated View.
The new examples will be forcus on using new API with all-in-one sample
codes and detailed documentation.
Reviewed By: ericvicenti
Differential Revision: D3354711
fbshipit-source-id: ac6360b1573989eb075d91cb9bf1ae8357dce7fa
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: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
Reviewed By: javache
Differential Revision: D3365346
fbshipit-source-id: d9cbf2865421f76772c1761b13992d40ec3675f0
Summary:
The API for `ActivityIndiatorIOS` and `ProgressBarAndroid` is very similar and can be merged in a cross platform component that displays a circular indeterminate loading indicator.
This deprecates `ActivityIndiatorIOS` and non-horizontal `ProgressBarAndroid` in favor of this new component.
**Test plan (required)**
Tested with the ActivityIndicator example in UIExplorer on android and ios. Also made sure that `ActivityIndicatorIOS` still works and displays a deprecation warning. Also tested that `ProgressBarAndroid` with `indeterminate == true` and `styleAttr != 'Horizontal'` displays a deprecation warning.
Closes https://github.com/facebook/react-native/pull/6897
Differential Revision: D3351607
Pulled By: dmmiller
fbshipit-source-id: b107ce99d966359003e8b3118cd97b90fa1d3d7d
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: CI_USE_PACKAGER flag was set only for testing, not running.
Reviewed By: nathanajah
Differential Revision: D3334982
fbshipit-source-id: 3f98e697bd144a4ac6d8d7cfabf546bb55de1695
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:
The refactor work (renamed `navigationState.children` to `navigationState.routes`) from D3333735
broken UI Explorer in Android. Fix it.
Reviewed By: ericvicenti
Differential Revision: D3334014
fbshipit-source-id: 345fbb5eabc792a49c6f2f82ce8c03679bc75940
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
[Experimental API breaking changes]
The notion of `parent` or `children` in navigaton is misleading. We have no intention to maintain or
build the nested or hierarchical navigation states. To be clear, rename `navigationState.children` to
`navigationState.route`.
Reviewed By: ericvicenti
Differential Revision: D3332115
fbshipit-source-id: c72ed08acaf030fb9c60abf22fb15cc0f44b3485
Summary:
[public / experimental API breaking change]
The data type of `scene.navigationState` is `NavigationRoute`. Rename `scene.navigationState` to
`scene.route` to avoid confusion such as treating `scene.navigationState` as the actual global navigation
state (type: NavigationState).
Reviewed By: ericvicenti
Differential Revision: D3331076
fbshipit-source-id: 3ed989cc8492d398cbeb1b12186459deb261d1fb
Summary:
This is the first step to clarify and simplify the type definations about navigation state.
For now, `NavigationParentState` is actually used as the real navigation state and `NavigationState` is used
as a route in navigation, which has been confusion among the APIs.
To be clear, our APIs has no intention and interest in dealing with nested or hierarchical navigation states,
and we should avoid have the name like `ParentState` or `children`.
To fully migrate the types, theer will be a lot of code changes and this is just the first step to rename.
= What's Next?
1. rename `navigationState.children` to `navigationState.routes` (breaking change!)
2. remove `navigationState.key` from its type defination.
Reviewed By: ericvicenti
Differential Revision: D3321403
fbshipit-source-id: 3e39b60f736c1135bc85d8bf2b89027d665e28d4
Summary:
It seems like the examples weren't working since the merge of `IntentAndroid` and `LinkingIOS` since they were still using `TouchableNativeFeedback` only available on Android.
The problem was also reported here : https://github.com/facebook/react-native/issues/7615
Closes https://github.com/facebook/react-native/pull/7655
Differential Revision: D3329233
fbshipit-source-id: 8c9cabaab0a616dab406c4e444c9fa6da5f54b6d
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:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary:
= Breaking Change (for experimental features) =
<NavigationView /> serves no obvious benefit and it's costly to maintain it.
- its features could be completely replaced by NavigationAnimatedView without
enabling the transtion animation.
- it could also be replaced with a simple view and normal scene renderer.
Reviewed By: ericvicenti
Differential Revision: D3280547
fbshipit-source-id: 4ac3dbe92ceb9107a1f6e77a78bd6021485e78a9
Summary:
The containers in NavigationExperimental are not appropraite because the state should be held by the app's architecture, be it redux, flux, or simple component state.
This diff moves the examples over to simple component state, but there are several other examples of how to use NavigationAnimatedView and the navigation reducers with redux:
- https://github.com/jlyman/RN-NavigationExperimental-Redux-Example
- Switching the f8 app with redux to navigation experimental: https://github.com/fbsamples/f8app/pull/14
Reviewed By: hedgerwang
Differential Revision: D3219911
fb-gh-sync-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
fbshipit-source-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
Summary:
This should simplify the renderScene usage a bit because the react key is required and this will make sure they are rendered with the right key automatically.
It changes the string to make sure people do not rely on this API for anything else.
Reviewed By: javache
Differential Revision: D3033933
fb-gh-sync-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
fbshipit-source-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
Summary:
NavigationLegacyNavigator was originally created to help people to migrate to the new
navigation library without API changes. Therefore we'd have to port all the old APIs that
don't necessarily seem align well with the new navigation library.
Consider the production usage of NavigationLegacyNavigator does not exist, it's better
to kill it and we'd just rename the `Navigator` to `NavigatorDeprecated` later instead.
Reviewed By: ericvicenti
Differential Revision: D3263704
fb-gh-sync-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
fbshipit-source-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
> From the existing documentation, it's not clear how one would make use of the highlightRow attribute of ListView.renderRow. Special thanks to halilb for his assistance.
Example: When "Adding a function to do X", explain why it is necessary to have a way to do X.
**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.
> Here's a screenshot of the UIExplorer with a row highlighted (using the FB Blue Color)
> <img width="466" alt="2016-03-16_1944" src="https://cloud.githubusercontent.com/assets/1640318/13835020/49b5b38c-ebb1-11e5-98fa-17201fd3db92.png">
Make sure tests pass on both Travis and Circle CI.
**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/CONTRIBUTIN
Closes https://github.com/facebook/react-native/pull/6495
Differential Revision: D3264092
Pulled By: nicklockwood
fb-gh-sync-id: 9608e8a66387f527b872928a3595ca4d17736b82
fbshipit-source-id: 9608e8a66387f527b872928a3595ca4d17736b82
Summary: This adds a new SceneView with a shouldComponentUpdate policy of only re-rendering when the scene's state changes. This allows avoidance of extra re-renders. Results in a much smoother back-swipe gesture because we no longer re-render scenes as we transition from gesture to animation.
Reviewed By: hedgerwang
Differential Revision: D3219545
fb-gh-sync-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
fbshipit-source-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
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.
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.
Or change it to yellow for demonstrating purposes
.
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: AaaChiuuu
fb-gh-sync-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
fbshipit-source-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
Summary:Fixes #6735
On font sizes smaller than 20, iOS will swap SystemFont to SF version optimised for smaller sizes which does not have ultralight and thin. That results in ultralight and light example to be rendered with the same weight.
Bumping to `20` makes it render differently as per below screenshot https://cloud.githubusercontent.com/assets/2464966/14622260/0789e500-05c9-11e6-920a-8c948a5b79b4.png
Closes https://github.com/facebook/react-native/pull/7044
Differential Revision: D3212565
Pulled By: mkonicek
fb-gh-sync-id: 5ffad136c7f4126c271366640c89673f30a99218
fbshipit-source-id: 5ffad136c7f4126c271366640c89673f30a99218
Summary:The Obj-C tests were stalling when we updated TravisCI to use the OS X image with Xcode 7.3 and iOS 9.3.
On my own MBP with Xcode 7.3 the tests stall as well. Running `./scripts/objc-test.sh` prints out a warning near the end, which says `ld` couldn't find a Frameworks folder under the iPhoneSimulator9.3 SDK directory. Indeed, this directory doesn't exist on my computer. When creating a brand new project with unit tests and UI tests, both test targets don't specify "Framework Search Paths" so I don't think we need to specify it anymore.
Closes https://github.com/facebook/react-native/pull/7168
Differential Revision: D3216524
fb-gh-sync-id: 3097bda98d78289ecdba86801bcd461f3311ac47
fbshipit-source-id: 3097bda98d78289ecdba86801bcd461f3311ac47
Summary:We no longer forward React onto this object. We only forward the ReactNative
module onto it.
We also deprecated the addons so they'll all warn. We'll remove it
completely soon.
Closes https://github.com/facebook/react-native/pull/7136
Reviewed By: gabelevi
Differential Revision: D3211809
Pulled By: sebmarkbage
fb-gh-sync-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
fbshipit-source-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: mkonicek
fb-gh-sync-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
fbshipit-source-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
Summary:This is a reprise of #6327, but with iOS 7.0 compatibility and less `package.json` changes.
**Test Plan:** Load WebSocketExample in UIExplorer app and start websocket test server script (both provided in #6889) and test sending binary data on both iOS and Android
Closes https://github.com/facebook/react-native/pull/6961
Differential Revision: D3202022
Pulled By: mkonicek
fb-gh-sync-id: 38843d0a9c0172971c5c70a5139ded04042b280a
fbshipit-source-id: 38843d0a9c0172971c5c70a5139ded04042b280a
Summary:- Get rid of no longer necessary WebSocket.js v WebSocketBase.js split
- Use `EventTarget(list, of, events)` as base class to auto-generate `oneventname` getters/setters that get invoked along with other event handlers
- Type annotation `any` considered harmful, especially when we can easily spell out the actual type
- Throw in some `const` goodness for free
**Test Plan:** Launch UIExplorer example app, supplied `websocket_test_server` script, and try different combinations of sending and receiving text and binary data on both iOS and Android.
Closes https://github.com/facebook/react-native/pull/6889
Differential Revision: D3184835
Pulled By: mkonicek
fb-gh-sync-id: f21707f4e97aa5a79847f5157e0a9f132a1a01cd
fbshipit-source-id: f21707f4e97aa5a79847f5157e0a9f132a1a01cd
Summary:Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
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.
**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).
Closes https://github.com/facebook/react-native/pull/6867
Differential Revision: D3186273
Pulled By: ericvicenti
fb-gh-sync-id: 35e82fe4389a271a30c49dd5a3bcbab7ac29a0cd
fbshipit-source-id: 35e82fe4389a271a30c49dd5a3bcbab7ac29a0cd
Summary:Currently React-Native does not have `ontimeout` and `onerror` handlers for [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest). This is an extension to [No timeout on XMLHttpRequest](https://github.com/facebook/react-native/issues/4648).
With addition to two handlers, both Android and iOS can now handle `ontimeout` if request times out and `onerror` when there is general network error.
**Test plan**
Code has been tested on both Android and iOS with [Charles](https://www.charlesproxy.com/) by setting a breakpoint on the request which fires `ontimeout` when the request waits beyond `timeout` time and `onerror` when there is network error.
**Usage**
JavaScript -
```
var request = new XMLHttpRequest();
function onLoad() {
console.log(request.status);
};
function onTimeout() {
console.log('Timeout');
};
function onError() {
console.log('General network error');
};
request.onload = onLoad;
request.ontimeout = onTimeout;
request.onerr
Closes https://github.com/facebook/react-native/pull/6841
Differential Revision: D3178859
Pulled By: lexs
fb-gh-sync-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
fbshipit-source-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
Summary:This change will change the returnKeyType to be "return" instead of being "done" since this example is trying to provide a example of a auto growing text input multiple use-case. It makes that the return key says just return in order to expand the input instead of done which does not really show the use of multiline.
Closes https://github.com/facebook/react-native/pull/6991
Differential Revision: D3184157
fb-gh-sync-id: dd0c21433009600d3cc585b941b089cab4895e7a
fbshipit-source-id: dd0c21433009600d3cc585b941b089cab4895e7a
Summary:Adds `Image.prefetch` to prefetch remote images before they are used in an actual `Image` component. This is based off of #4420 by sospartan and skevy's work.
Closes https://github.com/facebook/react-native/pull/6774
Differential Revision: D3153729
Pulled By: bestander
fb-gh-sync-id: ef61412e051a49b42ae885edce7905a8ca0da23f
fbshipit-source-id: ef61412e051a49b42ae885edce7905a8ca0da23f
Summary:This adds a BUCK file to UIExplorer to allow building it with buck. It is based on the one in the movies app but I removed the extra deps that were not needed in both files.
Also add build version number and target sdk version in the Android manifest so Buck can use it since it was only specified in the gradle build and caused the app to run on a super old target sdk.
bestander mkonicek Would it be simple to also build the ndk part with Buck? Right now it is built with gradle and packaged after. I suppose it is already being done internally at facebook. The BUCK files for building the cpp code are already there but I couldn't figure out what was missing to make it work :(
That is pretty much the only missing part to have first class support for building RN apps with Buck in OSS. We could eventually include BUCK files with the generated project.
**Test plan (required)**
Build and run UIExplorer and Movies examples using Buck.
Edited:
```
./gradlew ReactAndroid:packageReactNdkLibsForBuck
Closes https://github.com/facebook/react-native/pull/6399
Reviewed By: mkonicek
Differential Revision: D3042355
Pulled By: bestander
fb-gh-sync-id: 74760c7ba12d35b1853d2e3706c2ba130f9eef1c
fbshipit-source-id: 74760c7ba12d35b1853d2e3706c2ba130f9eef1c
Summary:First I searched for special cases that destructor PropTypes:
```
(?s)React\s*=\s*require\('react\-native'\).*(Children|PropTypes)[^\{\}]*\}\s*=\s*React;
```
I split them up manually.
Then I replaced the React = require('react-native') + destructuring pattern...
```
(?s)(const|var)\s+React\s*=\s*require\('react\-native'\)(.*[^\{\}]*\}\s*=\s*)React;
```
...with...
```
$1 React = require('react');
$1 ReactNative = require('react-native')$2ReactNative;
```
I used lint to figure out if I left some unnecessary imports.
Finally I grepped for just
```
React\s*=\s*require\('react\-native'\)
```
to catch any remaining patterns.
Also, `} = React.NativeModules` -> `} = ReactNative.NativeModules`.
Reviewed By: spicyj
Differential Revision: D3158991
fb-gh-sync-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
fbshipit-source-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
Summary:Update to new package split syntax + updated ReactART to a version that has
isomorphic rendering. D3154320.
Reviewed By: spicyj
Differential Revision: D3154434
fb-gh-sync-id: 7cfae5582de9040f10f5637c8c470310f42398f3
fbshipit-source-id: 7cfae5582de9040f10f5637c8c470310f42398f3
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary: Simplify and fix up a broken example
Reviewed By: hedgerwang
Differential Revision: D3137234
fb-gh-sync-id: 653086796d40a81f472274877fb890eee4b9b57b
fbshipit-source-id: 653086796d40a81f472274877fb890eee4b9b57b
Summary:Current docs show an Appetize.io example for AlertIOS doc. This pull request adds that feature across all applicable iOS and Android docs. So if a doc has an example in UIExplorer, it shows up in the top right and clicking to Play should navigate to the relevant example.
The changes here also touched NavigationExperimental to fix a typo that prevented iOS deep link from working. Code was also added to help support Android deep links but there's an outstanding issue (a race condition) around how Android deep links trigger getInitialURL in NavigationRootContainer that prevents this from fully working.
For adding the docs, a few things were done outside this pull request:
1/ Release builds for UIExplorer Android and iOS apps were uploaded to Appetize.io. The Appetize.io info (public key to run the build) is embedded in the docs.
2/ The iOS build was generated by making a few changes to get a local bundle. The current UIExplorer set up doesn't support "react-native run-ios".
Regarding the Appetize bu
Closes https://github.com/facebook/react-native/pull/6306
Differential Revision: D3129651
Pulled By: bestander
fb-gh-sync-id: d296d64db8236faa36f35484bb6b362990caf934
fbshipit-source-id: d296d64db8236faa36f35484bb6b362990caf934
Summary:D3092867 / 1d3db4c5dc caused deadlock when chrome debugging was turned on, so it was reverted as D3128586 / 144dc30661.
The reason: I was calling `[_bridge dispatchBlock:^{ [self flushEventsQueue]; } queue:RCTJSThread];` from main thread and expecting it will `dispatch_async` to another,
since a held lock was being accessed the dispatched block and was released after the dispatch.
Turns out `RCTWebSocketExecutor` (which is used when chrome debugger is turned on) executes all blocks dispatched this way to `RCTJSThread` synchronously on the main thread.
This resulted in a deadlock. The "dispatched" block was trying to acquired lock which held by the same thread in the dispatching phase.
A fix for this is pretty simple. We will release the lock before dispatching the block.
However it's not super straightforward to see this won't introduce some race condition in a case with two threads where we would end up with events not being processed.
My thinking why that shouldn't happen goes like this: We could get in a bad state if `flushEventsQueue` would run on JS thread while `sendEvent:` is running on MT.
(I don't have a specific example how, maybe it's not possible. However when I show this case is safe we know we are good.)
The way how locking is setup in this diff the only possible scenario where these two threads would execute in these methods concurrently is JS holding the lock and MT going to enqueue another block on JS thread (since that's outside of "locked" zone).
But this scenarion can never happen, since if MT is about to enqueue the block on JS thread it means there cannot be a not yet fully executed block on JS thread.
Therefore nothing bad can happen.
So this diff brings back the reverted diff and adds to it the fix for the deadlock.
Reviewed By: javache
Differential Revision: D3130375
fb-gh-sync-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
fbshipit-source-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
Summary:Fix spelling of the word letter. Was leter, now letter.
🐒
Closes https://github.com/facebook/react-native/pull/6780
Differential Revision: D3131714
fb-gh-sync-id: a368304267347211c139b09b82f6da12e8b67615
fbshipit-source-id: a368304267347211c139b09b82f6da12e8b67615
Summary:Previously, (mostly touch and scroll) event handling on iOS worked in a hybrid way:
* All incoming coalesce-able events would be pooled and retrieved by js thread in the beginning of its frame (all of this happens on js thread)
* Any non-coalesce-able event would be immediately dispatched on a js thread (triggered from main thread), and if there would be pooled coalesce-able events they would be immediately dispatched at first too.
This behavior has a subtle race condition, where two events are produced (on MT) in one order and received in js in different order.
See https://github.com/facebook/react-native/issues/5246#issuecomment-198326673 for further explanation of this case.
The new event handling is (afaik) what Android already does. When an event comes we add it into a pool of events and dispatch a block on js thread to inform js there are events to be processed. We keep track of whether we did so, so there is at most one of these blocks waiting to be processed. When the block is executed js will process all events that are in pool at that time (NOT at time of enqueuing the block).
This creates a single way of processing events and makes it impossible to process them in different order in js.
The tricky part was making sure we don't coalesce events across gestures/different scrolls. Before this was achieved by knowing that gestures and scrolls start/end with non-coalesce-able event, so the pool never contained events that shouldn't be coalesced together. That "assumption" doesn't hold now.
I've re-added `coalescingKey` and made touch and scroll events use it to prevent coalescing events of the same type that should remain separate in previous diffs (see dependencies).
On top of it it decreases latency in events processing in case where we get only coalesce-able events. Previously these would be processed at begging of the next js frame, even when js would be free and could process them sooner. This delay is done, since they would get processed as soon as the enqueued block would run.
To illustrate this improvement let's look at these two systraces.
Before: https://cloud.githubusercontent.com/assets/713625/14021417/47b35b7a-f1d3-11e5-93dd-4363edfa1923.png
After: https://cloud.githubusercontent.com/assets/713625/14021415/4798582a-f1d3-11e5-8715-425596e0781c.png
Reviewed By: javache
Differential Revision: D3092867
fb-gh-sync-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
fbshipit-source-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
Summary: This was previously removed in D2884587, but we will need it going forward. See D3092867 for reasons why it's necessary again.
Reviewed By: javache
Differential Revision: D3092848
fb-gh-sync-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
fbshipit-source-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
Summary:The navigation drawer of most apps on android opens over the status bar, this adds an option to do so. It implements a similar API to the native DrawerLayout by adding a statusBarBackgroundColor to DrawerLayoutAndroid.
Without statusBarBackgroundColor:
With statusBarBackgroundColor:
This PR depends on the changes in #6195 to add the `StatusBar.HEIGHT` constant I just want to put it out there now to see if this looks good. To test without the other PR just change `StatusBar.HEIGHT` for `25`.
It is implemented by making the native status bar translucent and making its background color transparent so we can draw a view of the same height as the status bar under it as a child of the DrawerLayoutAndroid. Then we can draw a semi-transparent gray View inside the drawer view to make it
Closes https://github.com/facebook/react-native/pull/6218
Differential Revision: D3017444
Pulled By: bestander
fb-gh-sync-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
fbshipit-source-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
Summary:This address the issue reported at
https://github.com/facebook/react-native/issues/6579#issuecomment-200984628
NavigationView should have the same API as NavigationAnimatedView does except
that NavigationView does not need the APIs for animation.
This unify the API of our core components so that people can freely
compose views with both NavigationAnimatedView or NavigationView.
Reviewed By: fkgozali
Differential Revision: D3096076
fb-gh-sync-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
fbshipit-source-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
Summary:Update CameraRoll examples to use promises because callbacks are deprecated.
Closes https://github.com/facebook/react-native/pull/6681
Differential Revision: D3102981
fb-gh-sync-id: c37bc2e470b7cb2aa4a9b3b21d76ddeb9cf3b71c
fbshipit-source-id: c37bc2e470b7cb2aa4a9b3b21d76ddeb9cf3b71c
Summary:- All the public sub component renderers should implement the interface
NavigationSceneRenderer, which will help to reuse renderer or
replace renders for different composition.
- Perf improvement. <NavigationHeader /> is rendering way more
sub component than necessary, we shall fix that.
- No UI or behavior change.
Reviewed By: ericvicenti
Differential Revision: D3091442
fb-gh-sync-id: fba5f7ce74597fa6036b5b216c02b06052801983
shipit-source-id: fba5f7ce74597fa6036b5b216c02b06052801983
Summary:sometimes it is nessesary to handle back button
specifically for component, by changing its state.
For ex. exit from edit mode.
Closes https://github.com/facebook/react-native/pull/5062
Differential Revision: D3084590
Pulled By: ericvicenti
fb-gh-sync-id: 13a4ea1d64ce725daa5d3af0d629a0c132a3f3d5
shipit-source-id: 13a4ea1d64ce725daa5d3af0d629a0c132a3f3d5
Summary:Add ability to specify custom left, right components, and title component. Style the `NavigationBar` according to the Platform.
Refer https://github.com/ericvicenti/navigation-rfc/pull/21
cc ericvicenti
Closes https://github.com/facebook/react-native/pull/5971
Differential Revision: D3080601
Pulled By: ericvicenti
fb-gh-sync-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
shipit-source-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary:This adds a `HEIGHT` constant on `StatusBar` on Android. I needed only this for now but I will work on a better status bar dimensions API later (see TODO).
It also improves the implementation to fix a bug that happened when multiple `StatusBar` components get updated in the same frame as well as remove useless calls to the `StatusBarModule` when values did not change.
Instead of calling the `StatusBarManager` immediately when the component gets updated and relying on the order of the calls that get dispatched to native we now wait at the end of the frame to send the calls to the `StatusBarManager` using `setImmediate`. To make this work properly we need to change the data structure of the props stack a little bit to store the desired transition/animation too for each value.
Finally this updates the example to only show the ones that work for the current platform.
**Test plan**
In the UIExplorer Example, in the 'StatusBar dimensions' section it should show 25 for the height of the status bar.
A
Closes https://github.com/facebook/react-native/pull/6195
Differential Revision: D3017559
fb-gh-sync-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
shipit-source-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
Summary: Port the legendary props `onWillFocus` and `onDidFocus` from `Navigator` to `NavigationLegacyNavigatorRouteStack`.
Reviewed By: fkgozali
Differential Revision: D3063530
fb-gh-sync-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
shipit-source-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
Summary:Per offline discussion with ericvicenti, we'd like to reudce the complexity by
keeping <NavigationCard /> nothing more than just a simple `<Animated.View />`,
which helps us to avoid over generalize the styles, gestures of what the Navigation card
needs to be.
The proposalis to use the same props (NavigationSceneRendererProps) that is used to render
the scene to generate the style and pan handlers needed for the navigation card.
No behavior changes, just implementation details clean up work.
Reviewed By: ericvicenti
Differential Revision: D3037225
fb-gh-sync-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
shipit-source-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
Summary:Adds a test so that people can create RCTBridgeModules that aren't auto-exported. This is useful for when you have more than one RCTBridge and want a module to be exposed in one but not the other.
RCTBridge/RCTBatchedBridge already supports this functionality; this diff adds a test so that it doesn't break.
Closes https://github.com/facebook/react-native/pull/6424
Differential Revision: D3044959
Pulled By: nicklockwood
fb-gh-sync-id: f8977249b1bf4023e704be6422ad77372d8f1714
shipit-source-id: f8977249b1bf4023e704be6422ad77372d8f1714
Summary:Removed eslint rule that checks modules
After we updated to ESLint 2.x, ESLint started complaining `'use strict' is unnecessary inside of modules strict`.
This is correct behaviour because according to spec modules are strict.
The problem is that our transforms don't transpile strict mode so we still need to have this pragma in all our code.
I did not find a way to make eslint require "use strict" for ES6 modules: https://github.com/eslint/eslint/issues/2785
So I am removing this.
What stops us from automatically adding strict mode with babel?
Need your feedback, frantic martinbigio
David said that you Martin looked into this.
Closes https://github.com/facebook/react-native/pull/6403
Differential Revision: D3038039
Pulled By: martinbigio
fb-gh-sync-id: b8a00c093768a318487dcb89e433859825a08b2c
shipit-source-id: b8a00c093768a318487dcb89e433859825a08b2c
Summary:Given that you can do all kinds of animations other than `Animated.timing`, it made no sense to have `setTiming`. In addition, you can't intuitively tell that this is the callback where you would do custom animations.
The discussion took place on Discord with ericvicenti: https://discordapp.com/channels/102860784329052160/154015578669973504
Closes https://github.com/facebook/react-native/pull/6235
Differential Revision: D2999121
Pulled By: hedgerwang
fb-gh-sync-id: f587b865de11ba5e8dc9c430720252ffb5d12794
shipit-source-id: f587b865de11ba5e8dc9c430720252ffb5d12794
Jeff Morrison
Ian Childs
Jing Chen
Nathan Azaria
Konstantin Raev
Hedger Wang
Tucker Connelly
Martín Bigio
alvaromb
Mike Lambert
Emil Sjolander
Janic Duplessis
Krzysztof Magiera
leeight
Andrei Coman
Sokovikov
Fabian Eichinger
Brandon Withrow
Nick Lockwood
Pieter De Baets
tantan
Paul Shen
Basil Hosmer
Adam Comella
Emilio Rodriguez
Raincal
Urban Cvek
Nicolas Charpentier
Corné Dorrestijn
Jimmy Mayoukou
Kevin Johnson
Eric Vicenti
Christine Abernathy
Chris Geirman
Jesse Sessler
Bruno Barbieri
Christoph Pojer
Alexander Blom
Nick Smith ♞
Jeff Chien
Mike Grabowski
James Ide
Sebastian Markbage
Alexey Lang
Tanguy Antoine
Philipp von Weitershausen
Gant
Skotch Vail
grgmo
Tomas Roos
Alexsander Akers
James Ide
Maxi Ferreira
Felix Oghina
Nick
Martin Konicek
Martin Kralik
Luqmaan Dawoodjee
Alex Kotliarskyi
Andy Street
Aleksei Androsov
Satyajit Sahoo
Alon Schwarz
Dave Miller
Richard Lai
Corentin Smith
