Summary:Since the React 0.14 split of modules, the findNodeHandle feature is part of the
renderer and not the generic React API.
This just greps for React.findNodeHandle and replace them with ReactNative.findNodeHandle. I fixed up the imports manually.
I also found two callers each of ReactNative.createClass and React.render with the exception of downstream and examples will fix them separately.
I'll need to find more things like `var { PropTypes } = ReactNative;` separately. I think this is a good start though.
Reviewed By: vjeux
Differential Revision: D3149356
fb-gh-sync-id: 50ed60bc67270b16f561d4c641f2f19e85724d3b
fbshipit-source-id: 50ed60bc67270b16f561d4c641f2f19e85724d3b
Summary:When navigating from one view to another you can still interact with
the current view. This means that a user can tap a button multiple times and trigger multiple transitions.
The view that is being transitioned off the screen should not be allowed to
receive any user interaction while it is being transitioned.
Reviewed By: javache
Differential Revision: D3143202
fb-gh-sync-id: cc033bbdf0cb9e717f62d2fcf751155406da846c
fbshipit-source-id: cc033bbdf0cb9e717f62d2fcf751155406da846c
Summary:There was an issue where the title component could overlap the left component and it would block the left component from receiving touches.
I only stumbled across this because we have a default title component which stretches most of the width and it was covering the edge of the left component. I think left/right components are more likely to be actionable than the title component so they should take priority in the touch order (ie. be rendered last).
Closes https://github.com/facebook/react-native/pull/6618
Differential Revision: D3144191
fb-gh-sync-id: 9ccd31714b2401d02eaaf4b5b24ed6afb60041c7
fbshipit-source-id: 9ccd31714b2401d02eaaf4b5b24ed6afb60041c7
Summary: The iOS native card stack only responds if the gesture starts on the left 30 px on the screen.
Reviewed By: hedgerwang
Differential Revision: D3137201
fb-gh-sync-id: 40e28d5696870b98731e92d6e42d00638b9bb15f
fbshipit-source-id: 40e28d5696870b98731e92d6e42d00638b9bb15f
Summary:Currently, if the Navigator with the default `NavigatorNavigationBar` has two scenes on its `routeStack` and the bottom one defines a `RightButton` but the top one doesn't, a touch to the location of the underlying `RightButton` will trigger its action.
This fix checks if the button's opacity is set to 0 (indicating it has been transitioned off the scene and shouldn't be interacted with) and ignores touch events if so.
Closes https://github.com/facebook/react-native/pull/5624
Differential Revision: D3139553
fb-gh-sync-id: 6d6da1459e289499b6d8769120a3b6114548c090
fbshipit-source-id: 6d6da1459e289499b6d8769120a3b6114548c090
Summary:At the beginning of the navigator docs it says " See Navigator.SceneConfigs for default animations and more info on scene config options."
but then this is the only information available:
<img width="658" alt="screen shot 2016-03-23 at 2 40 49 am" src="https://cloud.githubusercontent.com/assets/1247834/13977670/733cdaa6-f0a1-11e5-92e6-fc98725f65e0.png">
And the only way of knowing about the available options is to look at the source code. I think a lot of people will appreciate this...
If you think this is too much, maybe adding a link to the source code would help.
Closes https://github.com/facebook/react-native/pull/6599
Differential Revision: D3088592
fb-gh-sync-id: f11025b76441e9394ce42ed6c796fa1ace3e8c27
fbshipit-source-id: f11025b76441e9394ce42ed6c796fa1ace3e8c27
Summary: This will make the code more readable.
Reviewed By: ericvicenti
Differential Revision: D3096663
fb-gh-sync-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
fbshipit-source-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
Summary:The doc of props "navigationBar" in Navigator is not detailed enough. I make an improvement to it.
Closes https://github.com/facebook/react-native/pull/6615
Differential Revision: D3102065
fb-gh-sync-id: da96e3c422e053d0a8203bbd160ea10ed590878a
fbshipit-source-id: da96e3c422e053d0a8203bbd160ea10ed590878a
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:Currently there?s an inconsistency between the animations used in `NavigationAnimatedView` (`spring`) and those in `NavigationCardStack` (`timing`), which is noticeable when switching between the two implementations.
By removing the `_applyAnimation` method, the `NavigationAnimatedView` will simply use its [default `applyAnimation`](6c22a2174e/Libraries/NavigationExperimental/NavigationAnimatedView.js (L56-L67)), making the animation styles the same.
**Before** (with `Animated.timing`)
Video: http://quick.as/Yexku8DdJ
**After** (with the default `NavigationAnimatedView` animations)
Video: http://quick.as/qrqbsnj8n
Closes https://github.com/facebook/react-native/pull/6636
Differential Revision: D3094638
Pulled By: ericvicenti
fb-gh-sync-id: 6e1c7c54b4ef102c4003719381d334d2c6f7a531
shipit-source-id: 6e1c7c54b4ef102c4003719381d334d2c6f7a531
Summary: We need to support animation and gesture for Pager.
Reviewed By: ericvicenti
Differential Revision: D3066596
fb-gh-sync-id: 1c1a3d34b4298b4b0dd158f817057ae22dea72f4
shipit-source-id: 1c1a3d34b4298b4b0dd158f817057ae22dea72f4
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:Hi,
I am using https://github.com/aksonov/react-native-router-flux / https://github.com/exponentjs/ex-navigator and I needed a way to update my redux store with the current route.
I'm using the navigation context to do this:
```javascript
if (navigationContext) {
const handler = () => {
updateCurrentRouteState(navigationContext.currentRoute);
};
navigationContext.addListener('willfocus', handler);
navigationContext.addListener('didfocus', handler);
}
```
However, when the whole stack is replaced, no event is emitted. This PR aims to fix that.
Closes https://github.com/facebook/react-native/pull/5596
Differential Revision: D3080004
Pulled By: ericvicenti
fb-gh-sync-id: 0ef4ecebec7076275b6433c80aae6102cf28c039
shipit-source-id: 0ef4ecebec7076275b6433c80aae6102cf28c039
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:- Move the logics that manage the routes stack into `NavigationLegacyNavigatorRouteStack`
- Add more unit tests for NavigationLegacyNavigatorRouteStack.
- Keep NavigationLegacyNavigator as a pure view as possible as we could.
Reviewed By: fkgozali
Differential Revision: D3060459
fb-gh-sync-id: 2c6802115c3f6ca5e396903f0d314ff54129524c
shipit-source-id: 2c6802115c3f6ca5e396903f0d314ff54129524c
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: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
Summary:This is the initial implementation of the Navigator done with the NavigationExperimental library.
There will be following diffs to support more features that are currently available from the Navigator.
Reviewed By: ericvicenti
Differential Revision: D3016084
fb-gh-sync-id: ed509fc86e9dc67b5334be9e60b582494fd52844
shipit-source-id: ed509fc86e9dc67b5334be9e60b582494fd52844
Summary: I think we should dispose events in FIFO order
Reviewed By: fkgozali
Differential Revision: D2987425
fb-gh-sync-id: a4ad256512725d0bed0086b642e10fe7e7715070
shipit-source-id: a4ad256512725d0bed0086b642e10fe7e7715070
Summary: This fixes a couple of breakages introduced by the switch to fbjs
Reviewed By: bestander
Differential Revision: D3000078
fb-gh-sync-id: 2971d049030f754d5001f6729716373a64078ddf
shipit-source-id: 2971d049030f754d5001f6729716373a64078ddf
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary: Add card stack item that moves from the right or the bottom.
Reviewed By: ericvicenti
Differential Revision: D2975659
fb-gh-sync-id: a04724943375ba0a9931eafb2aa82d6d8c31acfe
shipit-source-id: a04724943375ba0a9931eafb2aa82d6d8c31acfe
Summary:Fix an issue when using ListView and define `renderSeparator` but the implementation returns null.
In such cases the sectionHeaderIndices mismatch the child element index and the app shows a warning like "Sticky header index 18 was outside the range {0, 13}".
Closes https://github.com/facebook/react-native/pull/5800
Differential Revision: D2980005
Pulled By: vjeux
fb-gh-sync-id: cd2d51d83698ed189bb65ea40b7b073644136b49
shipit-source-id: cd2d51d83698ed189bb65ea40b7b073644136b49
Summary:We'd plan to build the `NavigationLegacyNavigator` that is meant to replace
Navigator seemlessly without API changes. While the APIs remain
compatible with Navigator, it should be built with the new
Navigation API such as `NavigationAnimatedView`...etc.
To ensure that the new NavigationLegacyNavigagtor delivers the same
UX and maintains APIs compability, we'd start with using the exact same
examples as the same ones that Navigator uses.
Reviewed By: ericvicenti
Differential Revision: D2955273
fb-gh-sync-id: b4723cf54ea2258e5589f39dceeaee88be2b93f0
shipit-source-id: b4723cf54ea2258e5589f39dceeaee88be2b93f0
Summary:Basic implementation of the component NavigationCardStack that animates
a list of NavigationCard.
This will be used to port the UX of teh current Navigator.
Reviewed By: ericvicenti, fkgozali
Differential Revision: D2967065
fb-gh-sync-id: a72920e141364fab328e45a083aef21ca5e6fe0c
shipit-source-id: a72920e141364fab328e45a083aef21ca5e6fe0c
Summary: Revise APIs of reducers, and ensure the stack reducer can support sub-reducers
Reviewed By: javache
Differential Revision: D2959915
fb-gh-sync-id: 20b28b9ead7ace3373489a806486999048d32aef
shipit-source-id: 20b28b9ead7ace3373489a806486999048d32aef
Summary: There is a NavigationState type within this module so the name cannot be shared
Reviewed By: hedgerwang
Differential Revision: D2938311
fb-gh-sync-id: c5208755c9dfa5bf0e67666957c01e203ddd4218
shipit-source-id: c5208755c9dfa5bf0e67666957c01e203ddd4218
Summary:
public
I was looking into the missing panels at the bottom of the <ListView> - Grid Layout example, and found that it was caused by several problems, some in the example and some in ListView itself.
The first problem seemed to be a bug in the `_getDistanceFromEnd()` method, which calculates whether the ListView needs to load more content based on the distance of the visible content from the bottom of the scrollview. This was previously using the function
Math.max(scrollProperties.contentLength, scrollProperties.visibleLength) - scrollProperties.visibleLength - scrollProperties.offset
to calculate the amount the user could scroll before they run out of content. This sort-of works in most cases because `scrollProperties.contentLength` is usually longer than `scrollProperties.visibleLength`, so this would generally evaluate to
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
which meant that it would be positive as long as there was content still to be displayed offscreen, and negative when you reached the end of the content. This logic breaks down if `contentLength` is less than `visibleLength`, however. For example, if you have 300pts of content loaded, and your scrollView is 500pts tall, and your scroll position is zero, this evaluates to
Math.max(300, 500) - 500 - 0 = 0
In other words, the algorithm is saying that you have zero pts of scroll content remaining before you need to reload. But actually, the bottom 200pts of the screen are empty, so you're really 200pts in debt, and need to load extra rows to fill that space. The correct algorithm is simply to get rid of the `Math.max` and just use
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
I originally thought that this was the cause of the gap, but it isn't, because ListView has `DEFAULT_SCROLL_RENDER_AHEAD = 1000`, which means that it tries to load at least 1000pts more content than is currently visible, to avoid gaps. This masked the bug, so in practice it wasn't causing an issue.
The next problem I found was that there is an implict assumption in ListView that the first page of content you load is sufficient to cover the screen, or rather, that the first _ second page is sufficient. The constants `DEFAULT_INITIAL_ROWS = 10` and `DEFAULT_PAGE_SIZE = 1`, mean that when the ListView first loads, the following happens:
1. It loads 10 rows of content.
2. It checks if `_getDistanceFromEnd() < DEFAULT_SCROLL_RENDER_AHEAD` (1000).
3. If it is, it loads another `DEFAULT_PAGE_SIZE` rows of content, then stops.
In the case of the ListView Grid Layout example, this meant that it first loaded 10 cells, then loaded another 1, for a total of 11. The problem was that going from 10 to 11 cells isn't sufficient to fill the visible scroll area, and it doesn't change the `contentSize` (since the cells wrap onto the same line), and since ListView doesn't try to load any more until the `contentSize` or `scrollOffset ` changes, it stops loading new rows at that point.
I tried fixing this by calling `_renderMoreRowsIfNeeded()` after `_pageInNewRows()` so that it will continue to fetch new rows until the `_getDistanceFromEnd()` is less than the threshold, rather than stopping after the first page and waiting until the `contentSize` or `scrollOffset` change, but although this solves the problem for the Grid Layout example, it leads to over-fetching in the more common case of a standard row-based ListView.
In the end, I just increased the `pageSize` to 3 for the Grid Layout example, which makes more sense anyway since loading a page that is not a multiple of the number of cells per row confuses the `_renderMoreRowsIfNeeded` algorithm, and leads to gaps at the bottom of the view.
This solved the problem, however there was still a "pop-in" effect, where the additional rows were paged in after the ListView appeared. This was simply a misconfiguration in the example itself: The default of 10 rows was insufficient to fill the screen, so I changed the `initialListSize` prop to `20`.
Reviewed By: javache
Differential Revision: D2911690
fb-gh-sync-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
shipit-source-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
Summary:
public
- Intro new back action
- Add support in the two main reducers
- Use it in examples to support Android back button
- Disable NavigationCard gestures on Android
Reviewed By: hedgerwang
Differential Revision: D2914154
fb-gh-sync-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc
shipit-source-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc
Summary:
public
Navigator expects that the navigation bar implements the method to refresh itself.
NavigatorNavigationBar already has this method but not for NavigatorBreadcrumbNavigationBar.
Fix diff fixes this with the same fix as D2751922 did.
Reviewed By: wenjingw
Differential Revision: D2914475
fb-gh-sync-id: a2960bad5df3b403bdd2ab1dc4d349d7251b86c8
shipit-source-id: a2960bad5df3b403bdd2ab1dc4d349d7251b86c8
Summary:
A new API to unify internal navigation. Also addresses a highly-rated community 'pain': https://productpains.com/post/react-native/better-navigator-api-and-docs/
Offers the following improvements:
- Redux-style navigation logic is easy to reason about
- Navigation state can be easily saved and restored through refreshes
- Declarative navigation views can be implemented in native or JS
- Animations and gestures are isolated and now use the Animated library
public
Reviewed By: hedgerwang
Differential Revision: D2798048
fb-gh-sync-id: 88027ef9ead8a80afa38354252bc377455cc6dbb
Summary:
Since scrollTo(x,y,**animated**) params has been introduced, it was not backported to ListView scrollTo method.
Closes https://github.com/facebook/react-native/pull/5661
Reviewed By: svcscm
Differential Revision: D2886049
Pulled By: nicklockwood
fb-gh-sync-id: 016e92beadc7f397be77b8c58dc572119f873556
Summary:
To allow smoother API changes for users we often deprecate props and keep them around for a while before removing them. Right now it is all done manually, this adds a consistent way to show a warning when using a deprecated prop.
This also adds a deprecation warning of the website generated from the deprecatedPropType.
<img width="643" alt="screen shot 2016-01-26 at 7 43 08 pm" src="https://cloud.githubusercontent.com/assets/2677334/12600172/7af28fb0-c465-11e5-85e5-3786852bf522.png">
It also changes places where we added the warnings manually to use deprecatedPropType instead.
Closes https://github.com/facebook/react-native/pull/5566
Reviewed By: svcscm
Differential Revision: D2874629
Pulled By: nicklockwood
fb-gh-sync-id: c3c63bae7bbec26cc146029abd9aa5efbe73f795
Summary:
public
Map and Set are a standard JavaScript features, but are only supported in a subset of JSC versions that we target (e.g. iOS 7's JSC doesn't support Set).
The consequence of this is that failing to require('Set') before using it won't error during testing on a modern OS, but will fail on older OS versions. This diff makes the Map and Set polyfills available globally to all RN apps to avoid that problem.
Reviewed By: davidaurelio
Differential Revision: D2833997
fb-gh-sync-id: 713d8b69f6a1bce2472a1b2e6b84f69d75f30289
Summary:
Giving routeStack in second parameter of configureScene allows to do more advanced scene configuration.
I have use-case where I can only determine the scene config from the navigation context (not only from the route object but also from where it's located).
Closes https://github.com/facebook/react-native/pull/5254
Reviewed By: svcscm
Differential Revision: D2828415
Pulled By: androidtrunkagent
fb-gh-sync-id: 27b6c79b24cbc194e080541e9202ca84c55a0bc4
Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
Summary:
This fixes a regression introduced in df70005c12
If you set navigationBar props (on Navigator) and then later set it back to null, it will crashes.
(N.B. this should be possible as navigationBar is optional)
cc satya164
Closes https://github.com/facebook/react-native/pull/4941
Reviewed By: svcscm
Differential Revision: D2788889
Pulled By: bestander
fb-gh-sync-id: f8f1cd6cc2ce13b1b1b86fa76d3b22c26a8adb5b
Summary:
Closes#3870
Alternatively I could make this a bool `stickyheader` that just adds `0` to the `stickyHeaderIndices` passed down to the ScrollView.
Closes https://github.com/facebook/react-native/pull/4213
Reviewed By: svcscm
Differential Revision: D2807414
Pulled By: androidtrunkagent
fb-gh-sync-id: 091b6c6c91cebe175181f57b5c2785395b5db19b
Summary:
`FloatFromLeft` configuration was wrong. its animation was ok but the swipe back was wrong. for example you had to swipe from left to right for a `back` action which should be swipe from right to left.
`HorizontalSwipeJumpFromRight` is the same as `HorizontalSwipeJump` but for RTL layouts.
Closes https://github.com/facebook/react-native/pull/4815
Reviewed By: svcscm
Differential Revision: D2766720
Pulled By: androidtrunkagent
fb-gh-sync-id: 2b60f2d238a8f8e5b27dbfb307887934be477c81
Summary:
re-render the whole navigation bar while calling immediatelyResetRouteStack
from navigator.
Reviewed By: zjj010104
Differential Revision: D2751922
fb-gh-sync-id: 79bcd1457a96eaf3ca94b81da9bfecbec7f8af46
Summary:
Here is a showcase of 2 bugs that are fixed with this PR: touchability of title, touchability of overlapped top-right positionned (under the navbar).
(i'm using the inspector)
I have a navbar with a back button, a Title area with a **Green Circle**, a Right area with nothing inside.
In my Screen View, I've positioned in absolute a **Red Rectangle** just on the top-right corner under the navbar.
I want my **Green Circle** and **Red Rectangle** to be touchable but in current React Native version, this is not possible: as shown in the gif, the 3 LeftButton/Title/RightButton wrapper View are **catching the touch events**. My PR allows events to go through these wrapper View.
**After the fix:**
Complementary Notes:
- in the case of the Red Rectangle, only the lower part of it i
Closes https://github.com/facebook/react-native/pull/4786
Reviewed By: svcscm
Differential Revision: D2760205
Pulled By: androidtrunkagent
fb-gh-sync-id: 55bb141c8f61ab537ff9e832b65b04cb904dfeb9
Summary:
Docs say they're supported and presumably they should work exactly as for ScrollView but currently they are intercepted by the ListView
Closes https://github.com/facebook/react-native/pull/4712
Reviewed By: svcscm
Differential Revision: D2745080
Pulled By: vjeux
fb-gh-sync-id: 531907f03ae46d5200003cdb335c10b40c7d3bed
Summary:
about renderRow and renderSeparator.
insert a new line before description.
Closes https://github.com/facebook/react-native/pull/4532
Reviewed By: svcscm
Differential Revision: D2718764
Pulled By: androidtrunkagent
fb-gh-sync-id: eeefd16617fcb5e5ca21f6fd0cf29d63cb3b1f1c
Summary: Before that it was not possible to get a ref to a navigation bar (unless using Navigator's internal `_navBar` prop)
Closes https://github.com/facebook/react-native/pull/3755
Reviewed By: svcscm
Differential Revision: D2674315
Pulled By: nicklockwood
fb-gh-sync-id: 26120f7bcbb675e8217b8bd963dcc6ed314d4ba3
Summary: public
RCTUIManager is a public module with several useful methods, however, unlike most such modules, it does not have a JS wrapper that would allow it to be required directly.
Besides making it more cumbersome to use, this also makes it impossible to modify the UIManager API, or smooth over differences between platforms in the JS layer without breaking all of the call sites.
This diff adds a simple JS wrapper file for the UIManager module to make it easier to work with.
Reviewed By: tadeuzagallo
Differential Revision: D2700348
fb-gh-sync-id: dd9030eface100b1baf756da11bae355dc0f266f
Summary: public
The gesture that moves scene around should only be attached when the
move starts at the moment that the first move is granted.
No move would ever be granted if the move event is prevented by the
decendent children (e.g. a slider component).
For now, the move gesture is attached at `onPanResponderGrant`
instead of `onPanResponderMove` thus we'd create "ghost-move-gesture"
when no actual moves is received my the navigator.
Reviewed By: fkgozali
Differential Revision: D2683802
fb-gh-sync-id: 50ae877787167511df48378304bd2ad665c73300
Summary: public
Changed ListView to use onLayout and onContentSizeChange (new) events instead of measure. Updated ScrollView implementation to support contentSizeChange event with an implementation based on onLayout attached to the content view. For RecyclerViewBackedScrollView we need to generate that event directly as it doesn't have a concept of content view.
This greatly improves performance of ListView that uses RecyclerViewBackedScrollView
Reviewed By: mkonicek
Differential Revision: D2679460
fb-gh-sync-id: ba26462d9d3b071965cbe46314f89f0dcfd9db9f
Summary: I encounter issues when using ListView with multiple Sections.
```
...
var ds = new ListView.DataSource({
rowHasChanged : (row1, row2) => row1 !== row2,
sectionHeaderHasChanged : (s1, s2) => s1 !== s2
});
...
getInitialState: function() {
var sectionIDs = [0,1,2]
var rowIDs = [
[0,1,2],
[0,1,2],
[0,1,2]
]
var dataBlob = [
[blob0,blob1,blob2],
[blob3,blob4,blob5],
[blob6,blob7,blob8],
]
return {
dataSource : ds.cloneWithRowsAndSections(dataBlob, sectionIDs, rowIDs),
};
```
the code above would throw error because of duplicate key, as ''sectionID0 + rowID0 === sectionID1 + rowID1'. And I have to do:
```
...
sectionIDs.map((id)=>{
return id+'';
});
rowIDs.map((sec)=>{
return sec,map((id)=>{
return id+'';
});
});
...
```
ListView with sections does not seem to be documented yet, so I am not sure if this is the intended behaviour or am I missing anything. Co
Closes https://github.com/facebook/react-native/pull/4082
Reviewed By: svcscm
Differential Revision: D2652028
Pulled By: mkonicek
fb-gh-sync-id: a9933bac1a1ae2d6cbc73a11ef6aefde6fcdb35f
Summary: This issue shows up if you have a really long left nav item. When the navigator is pushed in iOS, the long nav item will be visible alongside the new nav item.
Steps to repro:
1/ Modify Examples/UIExplorer/Navigator/NavigationBarSample.js
2/ In NavigationBarRouteMapper.LeftButton, make the following change
<Text style={[styles.navBarText, styles.navBarButtonText]}>
Very Long Title {previousRoute.title}
</Text>
3/ On iOS, get the UIExplorer project up and navigate to Navigator > Navbar Example > Next (top-right nav item) > Next
You should see the overlap.
<img width="592" alt="leftnavitem_issue" src="https://cloud.githubusercontent.com/assets/691109/11086934/b5b82e26-880a-11e5-9945-13901346a5c5.png">
With these changes the overlap is gone.
Closes https://github.com/facebook/react-native/pull/4067
Reviewed By: svcscm
Differential Revision: D2641934
Pulled By: ericvicenti
fb-gh-sync-id: 962536b97f77a3b7f176423aa11dc94f24f07332
Summary: public
We've noticed that some of the navigator functions are called after the navigator
being unmounted. This diff adds the checks to protect the navigator from throwing
error when it's calling function after be unmounted.
Reviewed By: fkgozali
Differential Revision: D2629484
fb-gh-sync-id: 1cbee02b1a8d2a5d285e7d76f382d2599ed8caed
Summary: public
Now if you scroll up out of the end threshold and then back down into it,
onEndReached will get triggered again. This closes https://github.com/facebook/react-native/issues/1967
This also resets onEndReached when the data source changes. This would fix
issues where the data source changes and onEndReached should fire again since
the new data may have more pages, whereas the old data had reached the end and
stopped.
Reviewed By: jingc
Differential Revision: D2610799
fb-gh-sync-id: f6cef513a42d4765514bf4bc55d9e31a760117f1
Summary: 1. Add a new api `top` which returns the root navigator of a nested navigator.
2. Remove the param `context` from the method `addListener` because it's not used and not necessary.
public
Reviewed By: fkgozali
Differential Revision: D2613852
fb-gh-sync-id: 0d5544422ff0be7875824989a4fbefbef9aac986
Summary: This prevents the 'distanceFromEnd' from being negative when 'offset' is zero, for example.
Closes https://github.com/facebook/react-native/pull/3074
Reviewed By: svcscm
Differential Revision: D2610771
Pulled By: sahrens
fb-gh-sync-id: f878f1c1b865063294013c3bb96b90831877d372
Summary: public
Navigator subscribes to its internal animation spring that may still
asks navigator to re-render after being unmounted.
This diff clears the listeners of its animation spring once navigator
is unmounted.
Reviewed By: zjj010104
Differential Revision: D2588434
fb-gh-sync-id: 2b3ee65d3a6c3d45e5c6904d1dc65ac5a3e4534a
Summary: public
In Navigator, there are several places that mutate `this.state.presentedIndex`
with the express `this.state.presentedIndex = destIndex` instead of calling
`this.setState`, which creates the problem that not all internal states are
updated within the same React update cycle.
One of the symptoms is that over-swiping within the Navigator may throw JS error
due to `this.state.sceneConfigStack` and `this.state.presentedIndex` are not both
updated.
The workaround is to bypass the over-swiping gesture to avoid JS error.
Reviewed By: ericvicenti
Differential Revision: D2557140
fb-gh-sync-id: 1e5c9047ed17c04a63e2a568118848b00723fb1d
Summary: Adds the API that enables the navigation events capturing and bubbling which is the feature
that is enabled if the nested navigation contexts is created by the navigator.
This would allow developer to observe or reconcile navigation events within the navigation tree.
public
./Libraries/FBReactKit/jest
Reviewed By: zjj010104
Differential Revision: D2546451
fb-gh-sync-id: dfc9d16defaa563b9e80fd751a20570f6e524b74
Summary: This allows for the iOS-style navigation bar on Android and vice versa in order to simplify design. It is entirely optional in that NavigationBars will continue to defauly to their platform-specific style, but you can override it with the `navigationStyles` prop:
```js
<Navigator.NavigationBar
navigationStyles={Navigator.NavigationBar.StylesIOS}
/>
```
Fixes#2995.
Closes https://github.com/facebook/react-native/pull/3028
Reviewed By: @svcscm
Differential Revision: D2527902
Pulled By: @ericvicenti
fb-gh-sync-id: c7b1bfac200b5e03fc0d9dfb8acc8b916c825595
Summary: @public
Sometimes we want to load a very small number of rows initially and want the
onEndReached callback to be called immediately to trigger more data to be
loaded without waiting for the user to scroll at all. This diff makes that
happen by also checking on mount instead of only when scrolling.
Reviewed By: @vjeux
Differential Revision: D2507184
fb-gh-sync-id: ea8e47667d00387a935a426dd45afe978fd6d8cd
Summary: @public
Add method `stopPropagation` and `stop` to NavigationEvent so we can stop event easily once event bubbling and capturing is supported.
Reviewed By: @fkgozali
Differential Revision: D2471903
Summary: The component will crash if the prop is not provided. This helps with a better
error message in the console output.
Closes https://github.com/facebook/react-native/pull/2894
Reviewed By: @svcscm
Differential Revision: D2461752
Pulled By: @ericvicenti
Summary: When the touch gets terminated, it is not guaranteed that there is an active gesture. It looks like this was causing crashes
@public
Reviewed By: @chaceliang
Differential Revision: D2441469
Summary:
When mutation of a stack happens, we'd like to compute the diff of the stacks (before and after) so that
we can know which routes are removed in the new stack.
This diff adds a new method `substract` which does what we need.
Summary:
Disabling the scene this way would make the scene height go to zero and mess up the scroll position. By setting the bottom to the same distance, the view does not get resized and the scroll position is preserved through a scene disable cycle.
Summary:
# Summary
Add a method `keyOf` to NavigationRouteStack.
The method `keyOf` returns a key that is associated with the route.
The a route is added to a stack, the stack creats an unique key for it and
will keep the key for the route until the route is rmeoved from the stack.
The stack also passes the keys to its derived stack (the new stack created by the
mutation API such as `push`, `pop`...etc).
The key for the route persists until the initial stack and its derived stack no longer
contains this route.
# Why Do We Need This?
Navigator has needs to use an unique key to manage the scenes rendered.
The problem is that `route` itself isn't a very reliable thing to be used as the key.
Consider this example:
```
// `scene_1` animates into the viewport.
navigator.push('scene_1');
setTimeout(() => {
// `scene_1` animates off the viewport.
navigator.pop();
}, 100);
setTimeout(() => {
// Should we bring in a new scene or bring back the one that was previously popped?
navigator.push('scene_1');
}, 200);
```
Because we currently use `route` itself as a key for the scene, we'd have to block a route
until its scene is completely off the components tree even the route itself is no longer
in the stack otherwise we'd see strange animation of jumping scenes.
# What's Next
We're hoping that we can build pure reactive view for NavigationRouteStack easily.
The naive implementation of NavigationRouteStackView may look like this:
```
class NavigationRouteStackView {
constructor() {
this.state = {
staleScenes: {},
};
}
componentWillReceiveProps(nextProps) {
if (nextProps.stack !== this.props.stack) {
var stale;
var staleScenes = {...this.state.staleScenes};
this.props.stack.forEach((route, index, key) => {
if (nextProps.stack.keyOf(route) !== key) {
stale = true;
staleScenes[key] = {route, index, key, stale};
}
});
if (stale) {
this.setState({
staleScenes,
});
}
}
}
render() {
var scenes = [];
this.props.stack.forEach((route, index, key) => {
scenes.push({route, index, key});
});
Object.keys(this.state.staleScenes).forEach(key => {
scenes.push(this.state.staleScenes[key]);
});
scenes.sort(stableSortByIndex);
return <View>{scenes.map(renderScene)}</View>;
}
}
```
Summary:
If user taps the back button quickly, the app crashes becuase "pop"
internally only checks `this.state.presentedIndex` which does not
always update when transtion happens.
This diff addresses this issue.
Summary:
Hides disabled scenes using `top` instead of `left`, which fixes a bug with the native UITabBar. When the UITabBar's width is zeroed because the scene has `left: SCREEN_WIDTH, right: 0` applied, this triggers a bug with the kerning of the tab titles. Instead, zeroing the height by setting `top: SCREEN_HEIGHT` avoids the bug.
Also applies `pointerEvents="none"` to disabled scenes so that views in the off-screen scenes definitely don't receive touches, which was occurring before.
Fixes#1401, fixes#2011
Closes https://github.com/facebook/react-native/pull/2104
Github Author: James Ide <ide@jameside.com>
Summary:
Re-landing D2229686 after fixing bugs mentioned in D2250586
onItemRef is old and no longer needed now that the parent renders the scenes. This removes it from Navigator and all of our clients.
This is a breaking change to users of Navigator, but it is easy to transition to a ref in renderScene instead
Summary:
While adeveloper requests the emitter to emit an event, the emitter
may not emit the event immediately instead of putting the request
into a queue and process it later.
This diff allows the developer to provide a callback which will be called
when the event has been emitted.
For instance:
```
class NavigationContext {
push(nextRoute) {
var nextStack = this._stack.push(nextRoute);
this.emit(
'change',
{
reason: 'push',
nextStack: nextStack,
nextRoute: nextRoute,
},
this._onPush
);
}
_onPush(event){
if (event.defaultPrevented) {
return;
}
this._stack = event.nextStack;
this.emit('change');
}
}
```
Summary:
idStack is going away soon. This removes all references to it. Looking at the internal state of navigator will make you have a bad time.
The biggest change is switching to the new component-freezing techinique in the navigation bars. This way we avoid dependence on the idStack to provide a scalar ID for each route.
Summary:
Infinite scrolling in horizontal ListViews. Rather than just using height and Y offset to determine when to load more rows, it checks `props.horizontal` and switches between width/height and offset X/Y accordingly.
This changed required some renaming. However, the only change external to `ListView.js` is exporting `contentSize` instead of `contentHeight` from the `getMetrics()` function. (This is not part of the API, but is used "for perf investigations or analytics" and isn't reference in the repo).
I believe this change works as expected (and the xcode tests pass) though it's possible that there may more complexity in this issue that I have overlooked.
Closes https://github.com/facebook/react-native/pull/1786
Github Author: Mr Speaker <mrspeaker@gmail.com>
Summary:
onItemRef is old and no longer needed now that the parent renders the scenes. This removes it from Navigator and all of our clients.
This is a breaking change to users of Navigator, but it is easy to transition to a ref in renderScene instead
Summary:
When composing scroll views, `this.refs[SCROLLVIEW_REF]` may refer to another higher-order scroll component instead of a ScrollView. This can cause issues if you expect to need it to be a ScrollView backed by an RCTScrollView.
The solution is to call `getScrollResponder()` - as long as all higher-order scroll components implement this method, it will make its way down to the true ScrollView, which is what ListView wants here.
Closes https://github.com/facebook/react-native/pull/1927
Github Author: James Ide <ide@jameside.com>
Summary:
Introducing the data structure NavigationRouteStack that focused on managing
navigation routes stack.
The goal is to make <Navigatior /> thinner by moving stack management logic into
its own class and make sure it's well-tested.
Teh next step will be cleaning up <Navigatior /> and add `NavigationRouteStack` to
`NavigationContext`.
Summary:
A minor improvement suggestion: `Navigator.getCurrentRoutes()` probably shouldn't return its `routeStack` backing array as-is, because the caller may mutate it, causing the internal state of the navigator to go out of sync. Instead a shallow copy of the routes should be returned.
I stumbled on this problem in my app by attempting to read the navigator state as follows:
```
let routes = Navigator.getCurrentRoutes();
let current = routes.pop();
let previous = routes.pop();
```
Which led to an exception at next navigation event.
CLA signed.
Closes https://github.com/facebook/react-native/pull/1888
Github Author: Jani Evakallio <jani.evakallio@gmail.com>
Summary:
This enables code like:
```js
<ListView renderScrollView={() => <CustomScrollView />} />
```
where CustomScrollView might be inverted or support pull-to-refresh, etc.
Closes https://github.com/facebook/react-native/pull/785
Github Author: James Ide <ide@jameside.com>
Summary: At the moment the `ListView.js` `_childFrames` variable is only updated on scroll. As a consequence, `onChangeVisibleRows` won't get triggered for the initial render, nor any future render not trigered by scroll events. To fix this we need to make sure native and JS have the child frames in sync.
Summary:
When `UIManager.measure` is called from `componentDidMount` it causes the error "Attempted to measure layout but offset or dimensions were NaN". Deferring the layout by one frame solves this problem. Layout measurement is already asynchronous anyway, so I believe adding the `requestAnimationFrame` call doesn't affect the program's correctness.
Fixes#1749
Closes https://github.com/facebook/react-native/pull/1750
Github Author: James Ide <ide@jameside.com>
Test Plan:
Load UIExplorer and no longer get a redbox that says "Attempted to measure layout but offset or dimensions were NaN".
Summary:
This makes sure to call willFocus before new scenes get mounted. This fixes cases where the keyboard is dismissed on willfocus events which incorrectly happens *after* the autofocus in a new scene. The keyboard was opening and getting immediately closed
@public
Test Plan: Test keyboard autofocus in new nav scenes on iOS
Summary:
Updating range is too complicated. We can keep cached versions of the previously rendered scenes in a map.
@public
Test Plan: Verify that the active scene is the only thing that get re-rendered, and that rendering doesn't happen during transitions or gestures. Test navigation thouroughly in AdsManager
Sebastian Markbage
Hedger Wang
Morgan Pretty
Eric Vicenti
Kyle Corbitt
Bruno Barbieri
Nicolas Charpentier
Weijia Wang
Dom Christie
Satyajit Sahoo
Adrien Brault
Dilan Edirisinghe
Petr Glotov
Konstantin Raev
Richard Lai
Wenjing Wang
Martin Konicek
David Aurelio
Christoph Jerolimov
Nick Lockwood
Pieter De Baets
Olivier Notteghem
Gaëtan Renaudeau
Janic Duplessis
Eric Raio
Christoph Pojer
Emilio Rodriguez
Alex Rothberg
sunnylqm
Sameer Rahmani
Oleg Lokhvitsky
Justas Brazauskas
Thomas Parslow
moschan
Gabe Levi
Huang Yu
Danny Arnold
Krzysztof Magiera
Qiao Liang
Spencer Ahrens
Christine Abernathy
aleclarsoniv
Andy Street
James Ide
Elia Grady
Alex Coco
Jan Kassens
Tamara Woodson
Yamill Vallecillo
Emily Janzer
Rui Chen
Ben Alpert
Matheus Santos
Martín Bigio
Kevin Gozali
Mr Speaker
Jani Evakallio
Alex Kotliarskyi
