Summary:
For now, we emit `didFocus` event before fully resetting the transition and
hiding the stale scenes, so handler for `didFocus` event does not get the right
scenes in place. We should emit the didFocus event after resetting the transition and
hiding the stale scenes.
Reviewed By: ericvicenti
Differential Revision: D3299002
fbshipit-source-id: 6a79528097aabc4f61d4dba322820c228c889a84
Summary:
We want to give people the ability to log scroll performance (including Fb).
This adds an interface that can be enabled and disabled from the react scroll views.
This is a prerequisite to implementing the actual framerate logger that will log dropped
frames while scrolling in prod.
Reviewed By: astreet
Differential Revision: D3283588
fbshipit-source-id: ed9736cb9ed3f441511647f36b1460092bd91e56
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: b790b92e0fabb42488ff1135b1c37a3f0e9420f7
Summary: Center align text on Android
Reviewed By: fkgozali
Differential Revision: D3295222
fbshipit-source-id: c707d1102c8aa86aa04dc9b34a4746b1ff1543bc
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: 25ebad286d8b41f46c35c0f32d6023ebd01f19e7
Summary:
- Implemented a quick actions template to allow children buttons to be rendered in the slideout of `SwipeableListView`
- Implemented `QuickActionsButton` to allow buttons to be used in the slideout view
Reviewed By: fkgozali
Differential Revision: D3271946
fbshipit-source-id: b7c7412f44be64dea7084ca36c4b0f4f3842b008
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:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
- getScrollResponder returns a...ScrollView!
- no more var
- no more string refs
Reviewed By: spicyj
Differential Revision: D3286596
fbshipit-source-id: d9e6e0a318eadd2521c9f5c69d2ec368f1d7b626
Summary:
- Updated SwipeableListView to be much more performant by checking `rowHasChanged` more vigorously
- New `SwipeableListViewDataSource` used to mask implementation details from caller
Reviewed By: fkgozali
Differential Revision: D3272172
fbshipit-source-id: 02f66ed7fce7d587118ad7d82b20f8e78db44b7b
Summary:
React.PropTypes.oneOf accepts array as parameter, non-array given. this make the app throw a warning.
Closes https://github.com/facebook/react-native/pull/7498
Differential Revision: D3285737
fbshipit-source-id: 3d86b4b36d696e054f9225d7e3a9eddf91477813
Summary:
`tintColor`, even in style, works on Android; this must be some old comment but that confused me when reading the docs.
**Test plan:**
- Launched website locally
Closes https://github.com/facebook/react-native/pull/7465
Differential Revision: D3278166
fbshipit-source-id: 4e986e0f2a9ba05de4404b93d28687596fbb4fad
Summary:
The XMLHttpRequest jest tests were attempting to call a private method in XMLHttpRequestBase.js (denoted by an _ prefix).
JS doesn't actually have any language-level support for private methods, the use of _ prefix is just a convention. But to prevent casually calling private methods externally, we have a transform that mangles the names of prefixed methods so that that attempting to call them will fail.
Using a double _ bypasses this name-mangling mechanism, while still making it clear that the method is intended to be private.
Reviewed By: javache
Differential Revision: D3276261
fb-gh-sync-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
fbshipit-source-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
Summary: Move all requires of UIManager to UIManager.js, so we can load the view manager configuration lazily when UIManager is required.
Reviewed By: majak
Differential Revision: D3270147
fb-gh-sync-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
fbshipit-source-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
Reviewed By: javache
Differential Revision: D3275810
fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Summary:
Currently the Modal component on Android is rendered below the Status Bar, which changes it's color to grey, and in the UIExplorer example the backdrop is just formatted to look the same color. In some scenarios users may want to preserve the color of their status bar and make it look as though the modal is appearing on top. This PR allows for that.
This GIF shows current behavior and new behavior with the translucentStatusBar prop set to true.
I've updated the UIExplorer app to demonstrate and the docs as shown below
Thanks!
Closes https://github.com/facebook/react-native/pull/7157
Differential Revision: D3264497
Pulled By: dmmiller
fb-gh-sync-id: 61346d99414d331d3420f44a4c5f6341b0973be6
fbshipit-source-id: 61346d99414d331d3420f44a4c5f6341b0973be6
Summary:
Add the possibility to define a progress view top offset to RefreshControl on android. As i comment in #6740, contentInset does the trick on IOS.
Looking android documentation seems that exists a possible solution:
http://developer.android.com/reference/android/support/v4/widget/SwipeRefreshLayout.html#setProgressViewOffset(boolean, int, int)
This pull request implement that but keeping it simple, only a top offset.
For example, now we could put navigation bar over the scrollview (or listview) and define a progressViewOffset on RefreshView in order to start behind the navigation. At this point we could make some kind of coordinator layout to hide/show navigation on scroll.
To maintain the default behavior, start point is equal to start point minus progress circle diameter in order to create that progress circle before the start point.
Closes https://github.com/facebook/react-native/pull/6759
Differential Revision: D3240664
Pulled By: mkonicek
fb-gh-sync-id: ccf866272e871811c1c6dcc2a34f5c217967feee
fbshipit-source-id: ccf866272e871811c1c6dcc2a34f5c217967feee
Summary:
There was an issue with the way we made `RefreshControl` a controlled component when react doesn't render synchronously. This fixes the issue by using the same technique used in the commit 0cd2904b23 for`PickerAndroid`
**Test plan (required)**
Tested normal behaviour and tested that if not setting the `refreshing` prop to `true` during the `onRefresh` callback that the `RefreshControl` stops refreshing immediately. Also made sure that `setNativeProps` is only called if needed when the native refreshing state is not in sync with JS.
Fix#7414
Closes https://github.com/facebook/react-native/pull/7445
Differential Revision: D3274981
fb-gh-sync-id: a1b9d46329f552984e33d11fa0e29ad6da689511
fbshipit-source-id: a1b9d46329f552984e33d11fa0e29ad6da689511
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:
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 code change allows changing the transition velocity of the navigator
when switching views.
Whats the use case? If you have different types of
animations your animations might also need different transition velocities.
Closes https://github.com/facebook/react-native/pull/5439
Differential Revision: D3264719
Pulled By: ericvicenti
fb-gh-sync-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
fbshipit-source-id: 1bc0a1191ed3bd51b624acd161c3ee77fd748d72
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:
the prop type check for NavigationCard -> SceneView -> sceneRendererProps is wrong.
Fix it.
Reviewed By: ericvicenti
Differential Revision: D3265049
fb-gh-sync-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
fbshipit-source-id: 16e89c932f0f962db4b6a647d62d255ba98f6156
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:
This adds support for pagingEnabled to the HorizontalScrollView.
This is an initial implementation.
Because Android doesn't provide great details about what is happening with a scroll view after you are done touching it, we have some post touch handling. This is kicked off either by touch up or a fling call.
Once we are doing that handling, we start a runnable that basically checks if we are still scrolling. If we are, we just schedule that runnable again and check a frame later. If we are done scrolling (no onScrollChanged since we last fired), we could be in one of two states, the fling is done or we are done snapping to the page boundary. If we are in the fling done case, we then check if we need to scroll to a page boundary. If so, we call smoothScrollTo and schedule ourself to check onScroll events again until done with that scroll. If we are done with both (either we only did momentum scroll or we did that and then snapped to page), we can then fire the final event and stop checking. This logic is all in handlePostTouchScrolling.
Because of the decision to only do page scrolling after momentum ends, we do allow you to scroll through with momentum a number of pages and the transition can be a little strange where it stops a sec and then slides to be page aligned. As a follow up, we can probably smooth that up by changing the value we pass to super.fling() that would adjust it to be let momentum carry it to the page boundary.
Reviewed By: weicool
Differential Revision: D3207608
fb-gh-sync-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
fbshipit-source-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
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:
Allow changing distanceFilter after _locationManager has been initialized.
There is 2 reasons for this PR:
- When calling `getCurrentPosition`, `_observerOptions` is possibly not set properly ( as it is set only in `startObserving`), in this case it would have default values so `distanceFilter` will be 0 in this case ( which can be the right value but we should be more explicit about it, `kCLDistanceFilterNone` or `RCT_DEFAULT_LOCATION_ACCURACY`):
<img width="961" alt="screen shot 2016-04-14 at 8 44 09 pm" src="https://cloud.githubusercontent.com/assets/159813/14551465/6aa8791a-0288-11e6-9c98-1687357f8c2a.png">
- Another issue is that `distanceFilter` is cached so it can't be changed afterwards:
```javascript
let options;
options = {
enableHighAccuracy: true,
distanceFilter: 20,
};
this.watchId = this.geolocation.watchPosition(
() => { },
() => { },
options,
);
// => sets distanceFilter to 20
this.geolocation.clearWatch(this.watchId);
options = {
enableHighAccuracy:
Closes https://github.com/facebook/react-native/pull/6987
Differential Revision: D3258956
fb-gh-sync-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
fbshipit-source-id: 00a1d1b29d732a54cdc30e20a7a9a2de3dd9b725
Summary:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Hedger Wang
Jimmy Mayoukou
Nathan Spaun
Olivier Notteghem
Fred Liu
Nick Lockwood
Pieter De Baets
Kevin Johnson
Spencer Ahrens
nemothecapt
Ben Alpert
Eric Vicenti
Jesse Sessler
Alexander Blom
UnoDeTantos
Janic Duplessis
Alessandro Nadalin
wusuopu
Adam Comella
Sebastian Gronewold
Dave Miller
Chris Geirman
Jean-Richard Lai
Konstantin Raev
