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
David Aurelio
Hedger Wang
Christoph Jerolimov
Eric Vicenti
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
Satyajit Sahoo
moschan
Wenjing Wang
Gabe Levi
Huang Yu
Danny Arnold
