Summary:
This re-implements sticky headers in JS to make it work on Android.
The only change that was needed was to expose a way to attach a an animated value to an event manually since we can't use the Animated wrapper and `Animated.event` to do it for us because this is implemented directly in the `ScrollView` component. Simply exposed `attachNativeEvent` that takes a ref, event name and event object mapping. This is what is used by `Animated.event`.
TODO:
- Need to check why momentum scrolling isn't triggering scroll events properly on Android.
- Remove native iOS implementation
- cleanup / fix flow
**Test plan**
Test the example list in UIExplorer, test the ListViewPaging example.
Closes https://github.com/facebook/react-native/pull/11315
Differential Revision: D4450278
Pulled By: sahrens
fbshipit-source-id: fec8da2cffce9807d74f8e518ebdefeb6a708667
Summary:
Added a note to the `refreshControl` prop on ScrollView to call out that the prop only works for vertical ScrollViews.
Fixes#12139
Closes https://github.com/facebook/react-native/pull/12150
Differential Revision: D4508796
Pulled By: mkonicek
fbshipit-source-id: 8e71692f29ee175e32177c3a26a4ed2e8d14f139
Summary:
This prop exposes the functionality provided by Android ScrollView's setOverScrollMode method.
One interesting thing to note is that, if you were to read the Android docs, you would think that the value "always" is the default over scroll mode. However, the docs are incorrect and "always-if-content-scrolls" is actually the default value (http://stackoverflow.com/a/27116306).
**Test plan (required)**
Verified this change in a test app. Also, our team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10905
Differential Revision: D4500957
Pulled By: mkonicek
fbshipit-source-id: 873eba38183defba133c228e0c1038efa83297d3
Summary: `RecyclerViewBackedScrollView` was added a long time ago to work around the scroll-back-when-data-is-added bug, but that has now been fixed directly in the `ScrollView` (`ReactScrollView.java`) in open source and internally.
Reviewed By: astreet
Differential Revision: D4482105
fbshipit-source-id: 208f21f00045d5c5a83b74ad69b3db6fa63391d7
Summary:
This is a followup for https://github.com/facebook/react-native/pull/12088 and implements the scrolling to end on Android natively rather than sending a large scroll offset from JS.
This turned out to be an OK amount of code, and some reduction in the amount of JavaScript. The only part I'm not particularly happy about is:
```
// ScrollView always has one child - the scrollable area
int bottom = scrollView.getChildAt(0).getHeight() + scrollView.getPaddingBottom();
```
According to multiple sources (e.g. [this SO answer](http://stackoverflow.com/questions/3609297/android-total-height-of-scrollview)) it is the way to get the total size of the scrollable area, similar to`scrollView.contentSize` on iOS but more ugly and relying on the fact the ScrollView always has a single child (hopefully this won't change in future versions of Android).
An alternative is:
```
View lastChild = scrollLayout.getChildAt(scrollLayout.getChildCount() - 1);
int bottom = lastChild.getBottom() + scrollLayout.getPadd
Closes https://github.com/facebook/react-native/pull/12101
Differential Revision: D4481523
Pulled By: mkonicek
fbshipit-source-id: 8c7967a0b9e06890c1e1ea70ad573c6eceb03daf
Summary:
Hi,
The (as of yet unreleased) commit 5537055bf8 added some ListView and ScrollView mocks, but they leave out the original properties passed into them, which broke some of my tests (e.g. by excluding some properties like `testID`, for example, from the render tree) and I assume might break others' as well.
This PR makes it so the ListView mock directly returns the scroll component (instead of wrapping it in a View), and has ListViewMock and ScrollViewMock pass their given properties through.
Closes https://github.com/facebook/react-native/pull/11847
Differential Revision: D4408497
Pulled By: sahrens
fbshipit-source-id: 7ec01c35d6b8efeb97761cddffdb4075d09c7d70
Summary:
`Fake` components are simplified so snapshots are stable and reliable, and references are exported
so that interactions like `onRefresh` and `onScroll` can be called manually. Currently there is just
one global export for each class, but we may change this in the future if we need to manage multiple
`Fake`s of the same type in one render tree.
Right now these must be installed explicitly, but I might move them into `__mocks__` folders if it
seems reasonable to make them defaults.
Reviewed By: cpojer
Differential Revision: D4318207
fbshipit-source-id: 62802353a98b09ca1c80804ef7201ea63091f94a
Summary:
cc brentvatne
potential reviewers mkonicek and kmagiera
**Motivation for making this change.**
The previous PR was closed : #11095 but the followup actions was never done
I reopened a really similar one so it get merged
RecyclerView is no more used at Facebook (according to previous PR)
According to brentvatne, their were two motivations for RecyclerView:
* ListView with ScrollView component used to bounce back on row insert, but this is now fixed
* This made possible to implement certain performance improvements, but the maintenance cost was not worth the risk
With RN 0.37, the actual code in React Native make the app crash:
- see #10560
I spend one hour investigating this and did also require brent time at exponent slack. I think other people are struggling too.
**Test plan**
<img width="708" alt="screen shot 2016-12-13 at 23 42 22" src="https://cloud.githubusercontent.com/assets/13785185/21162483/dbeb642e-c18d-11e6-9c32-1fe73f1826c1.png">
**Code formatting**
The
Closes https://github.com/facebook/react-native/pull/11445
Differential Revision: D4340640
Pulled By: mkonicek
fbshipit-source-id: 64c5cf060f2eb035d4d6199b30f0e73afc520180
Summary:
Right now, the ScrollView's keyboard hiding behavior is either all or nothing: Hide the keyboard on any tap, or do nothing ever. This PR introduces a third mode to keyboardShouldPersistTaps which is much closer to what I consider should be the default.
In the new behavior, the tap responding is done in the bubbling phase (instead of the capture phase like =true). As a result, a child can handle the tap. If no child does, then the ScrollView will receive the tap and will hide the keyboard. As a result, changing TextInput focus works as a user expects, with a single tap and without keyboard hiding. But taping on Text or on the empty part of the ScrollView hides the keyboard and removes the focus.
You can view the behavior in a monkey patched ScrollView demo on rnplay:
https://rnplay.org/apps/E90UYwhttps://rnplay.org/apps/UGzhKA
In order to have a uniform props set, i added 3 values to the keyboardShouldPersistTaps:
'never' and 'always' are the same as false and true.
'handled' is the new behavior.
I don't
Closes https://github.com/facebook/react-native/pull/10628
Differential Revision: D4294945
Pulled By: ericvicenti
fbshipit-source-id: 1a753014156cac1a23fabfa8e1faa9a768868ef2
Summary:
Internal research at FB has shown that many devs don't know why they should use ListView instead of ScrollView, or that ListView even exists. This PR changes ScrollView's docs to upsell ListView.
I could put this as a separate guide in the docs, but I think this place will have the best possible reach for target audience.
Suggestions welcome. Let me know if it doesn't make sense or is too verbose.
Closes https://github.com/facebook/react-native/pull/11349
Differential Revision: D4292109
Pulled By: mkonicek
fbshipit-source-id: e4a14e5a55333c9282d0e407461505e71e850b20
Summary:
We got a report that onContentSizeChange function was being called with an object instead of a number for width, sometimes. Upon debugging, it looked like the param being passed in was a native event wrapper. Tim eventually figured out that this is because there's a TextInput child, and the event bubbles: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Text/RCTTextViewManager.m;afbdef32df50$39
Because ScrollView just passes all its props down to the component it eventually renders (RCTScrollView on iOS), the TextInput event bubbles up and triggers the onContentSizeChange prop that was passed in directly, instead of going through the layer in ScrollView that normally unpacks width/height from the native event: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Components/ScrollView/ScrollView.js;247ddb2022151b68dd9f83a888b6e0ec9923737a$413-416
Overriding the prop before passing down to RCTScrollView will break that chain, so that the event will continue to bubble but it won't find the incorrect prop from ScrollView.
Reviewed By: yungsters
Differential Revision: D3999689
fbshipit-source-id: d6c3bf711969b3e1c6fc1e51fd44c6894910bc3d
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
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).
For more info, see
Closes https://github.com/facebook/react-native/pull/10157
Differential Revision: D3974091
Pulled By: javache
fbshipit-source-id: c756fb82422253bb9098c37fbcb5637e58e53340
Summary: Changing from flex -> flexGrow on Scrollview caused some layouts to break due to having views below the scrollview. Adding flexShrink allows for the behavior again.
Reviewed By: blairvanderhoof
Differential Revision: D3936963
fbshipit-source-id: 0f43e6f5148918d3d431b98d26d185bbcc1548d0
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
Hi there,
when using the ScrollView component with `onScroll` and `scrollEventThrottle = 0` as it is documented in [react-native/docs/scrollview](https://facebook.github.io/react-native/docs/scrollview.html#scrolleventthrottle) this message will appear unnecessary.
This happens because `!this.props.scrollEventThrottle` is `true` when the value is `0`.
So I changed it to `this.props.scrollEventThrottle == null`. Now it is `false` when the value is `0`.
Closes https://github.com/facebook/react-native/pull/10038
Differential Revision: D3909323
fbshipit-source-id: 3c701f23708b64576a8c9f47e140d87159087894
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary:
I noticed that even when a ScrollView's `keyboardShouldPersistTaps` prop is set to true, the ScrollView's children can still respond to tap events (even if the scroll view itself will not respond to tap events and the keyboard does not dismiss automatically). This is a point of ambiguity in the React Native docs; it implies that no touch events can be handled if `keyboardShouldPersistTaps` is set to true.
Closes https://github.com/facebook/react-native/pull/9053
Differential Revision: D3636711
Pulled By: hramos
fbshipit-source-id: 2f0aea86202ab66d5a9174ce8611509dff67e15f
Summary:
In Android `RecyclerViewBackedScrollView` didn't provide the `scrollTo` API, however iOS does.
If a ListView was created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then calling `scrollTo` wouldn't work.
This diff enables the `scrollTo` API in `RecyclerViewBackedScrollView` on Android.
Reviewed By: dmmiller
Differential Revision: D3605233
fbshipit-source-id: f192053361f45453e5fce3fb6038ab03ac4025af
Summary:
In Android, `RecyclerViewBackedScrollView` wasn't using `refreshControl` prop.
If a ListView were created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then the `refreshControl` wouldn't work.
example:
```js
<ListView
dataSource={this.props.dataSource}
renderRow={this._renderRow.bind(this)}
refreshControl={
<RefreshControl
refreshing={this.props.isRefreshing}
onRefresh={this._onRefresh.bind(this)}
/>
}
renderScrollComponent={props => <RecyclerViewBackedScrollView {...props} />}/>;
```
This works in iOS, since the `RecyclerViewBackedScrollView` just returns an `ScrollView`.
This pull request uses the `refreshControl` to decide whether it should wrap the `NativeAndroidRecyclerView` with an
`AndroidSwipeRefreshLayout` or not.
This fixes the issue #7134.
Closes https://github.com/facebook/react-native/pull/8639
Differential Revision: D3564158
fbshipit-source-id: c10a880ea61cd80b8af789b00be90d46d63eaf9a
Summary: This removes `node_modules/react` from the list of directories that are used for haste module resolutions. Modules required from React are now imported with `require('react/lib/…')`.
Reviewed By: astreet
Differential Revision: D3509863
fbshipit-source-id: 32cd34e2b8496f0a6676dbe6bb1eacc18124c01e
Summary: ImageCropper is broken on iOS. Can not scroll up and down
Differential Revision: D3413397
fbshipit-source-id: 75096fc1d5dd14764c0ddd4fd3888a9576c1d1ce
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
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:
- getScrollResponder returns a...ScrollView!
- no more var
- no more string refs
Reviewed By: spicyj
Differential Revision: D3286596
fbshipit-source-id: d9e6e0a318eadd2521c9f5c69d2ec368f1d7b626
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:
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:
Just showing a hash of values is misleading. Makes the user think you can just pass in the values without the keys.
Closes https://github.com/facebook/react-native/pull/7310
Differential Revision: D3245834
fb-gh-sync-id: 39220ed7720e3ff402f2c2ba8bebdefb96bfa203
fbshipit-source-id: 39220ed7720e3ff402f2c2ba8bebdefb96bfa203
Summary:
I had to do a little trial and error to find this out. Would be helpful to have it in the docs.
I'm not sure if there's a standard wording or format you prefer for indicating handler function params.
Closes https://github.com/facebook/react-native/pull/7312
Differential Revision: D3245838
fb-gh-sync-id: 89433c036f7287d9efb69605180734dbc4df4df3
fbshipit-source-id: 89433c036f7287d9efb69605180734dbc4df4df3
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary:The website now displays public methods on components. This was implemented mostly in react-docgen via #66. This adds a <Method> component that is used by the component and API doc pages to display documentation for a method.
It also adds some missing documentation and tweak some existing one to integrate with this feature. I also prefixed some component methods with an '_' so they don't show up in the doc.
**Test plan (required)**
Tested every component page locally to make sure the methods doc was displayed properly.
Tested an API page to make sure it still worked properly.
Closes https://github.com/facebook/react-native/pull/6890
Differential Revision: D3159911
Pulled By: vjeux
fb-gh-sync-id: 1e6a4640cda6794496d9844c1af6a1451c017dcc
fbshipit-source-id: 1e6a4640cda6794496d9844c1af6a1451c017dcc
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: This property is only used by the native code as an optimization to not send events that no one is listening to. We don't need to expose it externally on the js api. Set sendMomentumEvent to be a native only property.
Reviewed By: bestander
Differential Revision: D3092650
fb-gh-sync-id: 95f5f0ae4cd04a7d1cbc9cf17c93647d3c644878
shipit-source-id: 95f5f0ae4cd04a7d1cbc9cf17c93647d3c644878
Summary: I see dead code
Reviewed By: bestander
Differential Revision: D3092668
fb-gh-sync-id: d80a0267aafd856b63e1d2ff1ae8b8e9f6deb8ce
shipit-source-id: d80a0267aafd856b63e1d2ff1ae8b8e9f6deb8ce
Summary:The docs indicated that a higher number was more accurate, however based on the implementation:
```
/**
* TODO: this logic looks wrong, and it may be because it is. Currently, if _scrollEventThrottle
* is set to zero (the default), the "didScroll" event is only sent once per scroll, instead of repeatedly
* while scrolling as expected. However, if you "fix" that bug, ScrollView will generate repeated
* warnings, and behave strangely (ListView works fine however), so don't fix it unless you fix that too!
*/
if (_allowNextScrollNoMatterWhat ||
(_scrollEventThrottle > 0 && _scrollEventThrottle < (now - _lastScrollDispatchTime)))
```
https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L564
It appears that only 0 is a special case here, and perhaps a known issue ;)
Closes https://github.com/facebook/react-native/pull/3729
Differential Revision: D3074801
Pulled By: mkonicek
fb-gh-sync-id: f63b00755f7565165cc628085efa5ed96badcfe1
shipit-source-id: f63b00755f7565165cc628085efa5ed96badcfe1
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?
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.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
See the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
Closes https://github.com/facebook/react-native/pull/6454
Differential Revision: D3049074
Pulled By: sahrens
fb-gh-sync-id: 61d085bb5c7bedf80204cdfb94e5c23542e15333
shipit-source-id: 61d085bb5c7bedf80204cdfb94e5c23542e15333
Summary: The exportedConstants method incurrs a penalty at bridge startup time for every module that implements it. This diff removes exportedConstants from a few modules that don't really need to use it.
Reviewed By: majak
Differential Revision: D2982341
fb-gh-sync-id: be016187d7b731a073311daacfcf88a0402e1688
shipit-source-id: be016187d7b731a073311daacfcf88a0402e1688
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:
Perhaps there is a better way to do this, curious to hear it!
- If momentum scroll is active when `scrollEnabled` is toggled, the momentum scroll continues and the onMomentumScrollEnd event fires, which is the same as on iOS.
Closes https://github.com/facebook/react-native/pull/5656
Reviewed By: svcscm
Differential Revision: D2889897
Pulled By: dmmiller
fb-gh-sync-id: b2f44d2bcb48373f9945f6afd966447a118df717
Summary:
The issue is that the ScrollResponder mixin assumes that the native scrollable node is the top level element and gets it using `React.findNodeHandle(this)` but since Android wraps the native `ScrollView` component with the `RefreshControl`, it finds the native `RefreshControl` node instead and the scroll command gets ignored because it doesn't exists.
This adds a hook to ScrollResponder mixin to allow specifying what is the native scrollable node.
The bug can be reproduced using this https://gist.github.com/janicduplessis/871c0b6d3ad0acaacba9 in UIExplorer.
Fixes#5725
Closes https://github.com/facebook/react-native/pull/5736
Reviewed By: svcscm
Differential Revision: D2896125
Pulled By: nicklockwood
fb-gh-sync-id: 0a00a20551421982c5bc519c542774877ba15c9b
Summary:
public
The current `ScrollView.scrollTo()` API is confusing due to the `(y, x)` parameter order, and the boolean `animated` argument. E.g.
ScrollView.scrollTo(5, 0, true) // what do these arguments mean?
This diff replaces the API with a configuration object, so the arguments are all explicit:
ScrollView.scrollTo({x: 0, y: 5, animated: true}) // much better
The `scrollTo()` method checks the argument types, and provides backwards compatibility with the old argument format for now. Using the old API will generate a warning, and this will eventually be upgraded to an error.
Reviewed By: davidaurelio
Differential Revision: D2892287
fb-gh-sync-id: cec4d504242391267c6e863816b6180ced7a7d5e
Summary:
Original Android's refreshControl in ScrollView is tightly coupled with AndroidSwipeRefreshLayout. If someone use `ref=` for RefreshControl in ScrollView, it does nothing since RefreshControl in Android return null.
This change allows customized RefreshControl especially for `ref=` as well as making ScrollView's code clearer.
Closes https://github.com/facebook/react-native/pull/5623
Reviewed By: svcscm
Differential Revision: D2890072
Pulled By: nicklockwood
fb-gh-sync-id: a8fc7746bcc050a6e46fedf3583979f4cb9021b6
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:
Expose a `decelerationNormalEnabled` flag on WebView, which, when enabled, will WebView's ScrollView's `decelerationRate` to `UIScrollViewDecelerationRateNormal`. This gives the WebView the same "momentum" style scrolling as other iOS views.
This was discussed with ide in #5447. Please let me know if there's anything I'm missing, or anything else you'd like to see in this pull request.
Closes https://github.com/facebook/react-native/pull/5527
Reviewed By: svcscm
Differential Revision: D2870312
Pulled By: nicklockwood
fb-gh-sync-id: 7dbfd06a349e3365a5df40c3bacf25a4fdb306cf
Summary:
public
This diff deprecates `scrollResponderScrollWithoutAnimationTo` and replaces it with an optional `animated` param in `scrollResponderScrollTo`. This is more consistent with our other APIs.
Using the old `ScrollResponder.scrollResponderScrollWithoutAnimationTo` or `ScrollView.scrollWithoutAnimationTo` functions will still work, but will trigger a warning.
Reviewed By: javache
Differential Revision: D2823479
fb-gh-sync-id: 259966512104ca7b3995c9586144812a91b8d3e9
Summary:
Exposes the doc for RefreshControl and add a link to the component page in ScrollView.
Closes https://github.com/facebook/react-native/pull/5209
Reviewed By: svcscm
Differential Revision: D2818217
Pulled By: mkonicek
fb-gh-sync-id: eb1ae70103e6a02af3a12866509f68eacc413dfd
Summary:
Both iOS and Android currently support some sort of native pull to refresh control but the API was very different. I tried implementing a component based on PullToRefreshViewAndroid but that works on both platforms.
I liked the idea of wrapping the ListView or ScrollView with the PullToRefreshView component and allow styling the refresh view with platform specific props if needed. I also like the fact that 'refreshing' is a controlled prop so there is no need to keep a ref to the component or to the stopRefreshing function.
It is a pretty rough start so I'm looking for feedback and ideas to improve on the API before cleaning up everything.
On iOS we could probably deprecate the onRefreshStart property of the ScrollView and implement the native stuff in a PullToRefreshViewManager. We could then add props to customize the look of the UIRefreshControl (tintColor). We could also deprecate the Android only component and remove it later.
Closes https://github.com/facebook/react-native/pull/4915
Reviewed By: svcscm
Differential Revision: D2799246
Pulled By: nicklockwood
fb-gh-sync-id: 75872c12143ddbc05cc91900ab4612e477ca5765
Summary:
Allows you to do:
```
var { RecyclerViewBackedScrollView } = require('react-native')
```
Rather than:
```
var RecyclerViewBackedScrollView = require('react-native/Libraries/Components/ScrollView/RecyclerViewBackedScrollView')
```
Also...
- Export `ScrollView` by default rather than `UnimplementedView` for `RecyclerViewBackedScrollView` on iOS -- this makes it easier on the user, so you don't have to always do a conditional for: `if IOS then use ScrollView else use RecyclerViewBackedScrollView`. I can't think of a case where this would lead to undesirable behaviour.
- Add `RecyclerViewBackedScrollView` to `MainReactPackage`
- Fix an issue with `MapView` that threw a red-screen when trying to access constants on Android because there is no `MapView` in open source and MapView.js doesn't have a platform extension.
Closes https://github.com/facebook/react-native/pull/4514
Reviewed By: svcscm
Differential Revision: D2753466
Pulled By: mkonicek
fb-gh-sync-id: 0b6e2133975c911d5117e7531cb9093faf314c52
Summary:
public
This adds support for
onScrollBeginDrag/End
onMomentumScrolBegin/End
Reviewed By: astreet
Differential Revision: D2739035
fb-gh-sync-id: 2a49d1df54e5f5cd82008bdb0ffde0881ba39aff
Summary: The recent commits for RecyclerViewBackedScrollView introduced a bunch of Flow errors.
Disable Flow for now in `ReactNativeViewPool` as it looks like that file doesn't use Flow :)
public
Reviewed By: gabelevi
Differential Revision: D2679974
fb-gh-sync-id: 71512f403e3fa271f6c0fa1a64e877ca1750f675
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: `ScrollView.scrollWithoutAnimationTo` is supported on iOS but not Android. This is an existing API, and this diff adds Android support.
Closes https://github.com/facebook/react-native/pull/2695
Reviewed By: @svcscm
Differential Revision: D2452630
Pulled By: @mkonicek
Summary:
The `ScrollView` component tells the native side the subview indices of the views to make sticky. The problem is that, once layout-only views are collapsed, the indices are no longer reflective of the original views to make stick to the top.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
@public
Test Plan: There are tests in `RCTUIManagerTests.m` that test the tag- and index-manipulation logic works. There are various scenarios including add-only, remove-only, and move. In addition, two scenario tests verify that the optimization works by checking the number of views and shadow views after various situations happen.
Summary:
As discussed in our internal group, think this is a fairly easy error to run into so I added some explanation.
@frantic / @vjeux open to better wording here, but I tried to explain how setting the height directly is discouraged and it's probably better to pipe `flex: 1` all the way down.
I didn't regenerate the website since the script assumes some permissions (push permission to master repo) and has some missing npm dependencies (and after fixing that, still had some obscure error :P )
Closes https://github.com/facebook/react-native/pull/1633
Github Author: Peter Cottle <pcottle@fb.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
This is a proposal to add `getScrollResponder` to all ScrollView-like components, including ListView. This allows multiple higher-order scroll views to be composed while allowing the owner of the top-level scroll view to call `scrollableView.getScrollResponder().scrollTo(...)` regardless of whether `scrollableView` is a ScrollView, ListView, InvertedScrollView, etc.
Closes https://github.com/facebook/react-native/pull/766
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Spencer Ahrens
Janic Duplessis
Jon Cursi
Valentin Shergin
Adam Comella
Martin Konicek
Dan Hassin
tychota
Maxime Lapointe
Martin Konicek
Linmic
Tim Yung
Jing Chen
Nader Dabit
Emil Sjolander
Dustin Hoffner
Simon Ayzman
Siqi Liu
Leonardo Tegon
David Aurelio
Wenjing Wang
Nathan Spaun
Pieter De Baets
Dave Miller
Joshua Pinter
Nick Lockwood
Sebastian Markbage
Nick Hudkins
Szabó Krisztián
Konstantin Raev
Austin Kuo
Keith Norman
Brent Vatne
Kudo Chien
August Flanagan
Jean Regisser
Justas Brazauskas
Roman Telicak
Krzysztof Magiera
EwanThomas
rxb
James Ide
Andrei Coman
Philipp von Weitershausen
Rui Chen
Ben Alpert
Alex Akers
chaceliang
Peter Cottle
Gabe Levi
Tadeu Zagallo
