Summary:
Close#13500
I've been bothered by this issue for quite a long time, finally get some time to look into it.
I find the root cause is that after a prop of the native driven node is assigned with a plain value, if you set it to be a `Animated.Value` again , it will take no effect any more, so I just keep it be a `Animated.Value` all the time.
`value --> Animated.Value (✅) --> value (✅) --> Animated.Value (❌)`
ping janicduplessis
Closes https://github.com/facebook/react-native/pull/13885
Differential Revision: D5077094
Pulled By: javache
fbshipit-source-id: 3fb5d8196d94101200394b2bb2b95c776fb1d2f3
Summary:
There was an issue that sometimes sticky headers would stop moving when re-rendering because we did not reattach events properly. This makes sure that we always detach and reatach on rerender in case the scroll view ref changes.
**Test plan**
Tested that this fixes issues with sticky headers we discovered when updating Expo to RN 0.44.
Closes https://github.com/facebook/react-native/pull/14012
Differential Revision: D5094418
Pulled By: javache
fbshipit-source-id: a56050ae786712e8a3de2a6e3b4e8749a2fde86e
Summary:
cc hramos
Pretty sure I've hit all of the places where AppRegistry is called in CRNA-pastable examples. Let me know whether you think we need to approach the version lag differently, I figure a caveat is as natural a place to call it out as any.
If you end up finding anything else that needs tweaking before cherry picking, I'm happy to push that up here too.
Closes https://github.com/facebook/react-native/pull/13744
Differential Revision: D5071038
Pulled By: hramos
fbshipit-source-id: 4a4a6f2a73079aca627f17d75a4e4b395ecbd4a8
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The current code for IOS contains deprecated code for incoming urls.
in iOS 10 deprecated openURL.
more details here: https://useyourloaf.com/blog/openurl-deprecated-in-ios10/
1. Create an RN app with iOS 10. set up linking as per instructions.
2. Using the iOS9 code snippet, with the app is open, navigate to the apps url scheme (in safari) appname://value1/value2, the eventListener will not trigger. note: it will however trigger getInitialURL if app is closed.
3. Replace the old iOS9 code with the iOS 10 and trigger an incoming url from a browser appname://
with the new code in the doc it will trigger for both open and closed apps.
Closes https://github.com/facebook/react-native/pull/13942
Differential Revision: D5071851
Pulled By: hramos
fbshipit-source-id: 8394de73014a1d2a5982b22b1b6fd09e0cf524dd
Summary:
Added a missing license header to UnimplementedView.js
No code logic got changed, just added a comment. So the regular CircleCI tests should be fine.
Closes https://github.com/facebook/react-native/pull/13952
Differential Revision: D5056778
Pulled By: javache
fbshipit-source-id: feb106946a9a34cfdf2df63de21305ac779296f4
Summary:
And clean it up.
**TestPlan**
No more warning when launching RNTester
LayoutAnimationExample still works, also without warnings.
Reviewed By: fkgozali
Differential Revision: D5055050
fbshipit-source-id: a3a6cdf25632dc4f9455d795e8a2e3c00f968e09
Summary:
D5016368 to suppress the warning had a typo which meant `_isMounted` would never get set
`false` and thus some functions could be called on unmounted refs.
Reviewed By: yungsters
Differential Revision: D5034076
fbshipit-source-id: 6334db6ee2f9e19c1bb4da2572987dc10773e28d
Summary:
The list items' selected state is inside the `selected` Map, not inside the `state`.
This PR corrects a small mistake in the minimal example in the Documentatioin of the FlatList component.
1. Create a vanilla React Native project.
2. Create the components involved in the minimal example of FlatList.
3. Run to see if the `selected` property of the `MyListItem` changes as intended.
Currently the example has this mistake so an error will show up when running:
Closes https://github.com/facebook/react-native/pull/13795
Differential Revision: D5010105
Pulled By: javache
fbshipit-source-id: 09585cea2f2e3e6746419ef54ef8da9dbdb8dbb1
Summary: Exporting an object instead of an array so it can be used as an enum by other files.
Reviewed By: sahrens
Differential Revision: D5007488
fbshipit-source-id: 8253a424f0dbb51511b889b1da637f366c0f290a
Summary:
Hey there :)
Please let me know if the name `ListEmptyComponent` should be changed. I also thought about `ListNoItemsComponent`. Or maybe `ListPlaceholderComponent`?
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
In a FlatList, I wanted to show some placeholder when my data is empty (while keeping eventual Header/Footer/RefreshControl).
A way around this issue would be to do something like adding a `ListHeaderComponent` that checks if the list is empty, like so:
```js
ListHeaderComponent={() => (!data.length ? <Text style={styles.noDataText}>No data found</Text> : null)}
```
But I felt it was not easily readable as soon as you have an actual header.
This PR adds a `ListEmptyComponent` that is rendered when the list is empty.
I added tests for VirtualizedList, FlatList and SectionList and ran `yarn test -- -u`. I then checked that the snapshots changed like I wanted.
I also tested this against one of my project, though I had to manually add my changes because the project is on RN 0.43.
Here are the docs screenshots:
- [VirtualizedList](https://cloud.githubusercontent.com/assets/82368/25566000/0ebf2b82-2dd2-11e7-8b80-d8c505f1f2d6.png)
- [FlatList](https://cloud.githubusercontent.com/assets/82368/25566005/2842ab42-2dd2-11e7-81b4-32c74c2b4fc3.png)
- [SectionList](https://cloud.githubusercontent.com/assets/82368/25566010/368aec1e-2dd2-11e7-9425-3bb5e5803513.png)
Thanks for your work!
Closes https://github.com/facebook/react-native/pull/13718
Differential Revision: D4993711
Pulled By: sahrens
fbshipit-source-id: 055b40f709067071e40308bdf5a37cedaa223dc5
Summary:
The main reason to use **VirtualizedList** is to set the `getItem` and `getItemCount` props, so having default values for these props makes things error prone.
* In **VirtualizedList**, changed the `getItem` and `getItemCount` props from optional to required, and removed default values.
* Ensured that implementing classes **FlatList** and **SectionVirtualizedList** are always passing these props.
* Updated VirtualizedList-test.js accordingly.
Reviewed By: sahrens
Differential Revision: D4980236
fbshipit-source-id: ad1838931253bc61ff9068c40929f6e9c755b92c
Summary:
- If the initial render doesn't extend past `onEndReachedThreshold` it is likely that onEndReached won't get called until scroll, which can be a bad experience if the `initialNumToRender` is very close to the viewport height. This happens because when `onContentSizeChange`, `onLayout` may not have fired yet so we don't know what the `visibleLength` is. Fix is to also call `maybeCallOnEndReached` in `_onLayout` as well.
- We have an optimization that does hi-pri render window updates when scrolling quickly and the content reaches the edge of the viewport, but there is also an important case where the user has scrolled to the end of the content and is waiting for a network response. Once the new data comes in, we want to render it ASAP because the user is waiting for it. To solve this we refactor our scheduling code into a shared function that always checks if it should be a hi-pri update instead of just in `_onScroll`.
Reviewed By: bvaughn
Differential Revision: D4975314
fbshipit-source-id: 8d64832ecbcbdbac430a08a4018d7a32b2216a85
Summary:
- [x] Explain the **motivation** for making this change.
- [ ] ~Provide a **test plan** demonstrating that the code is solid.~
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The key name required to access the CameraRoll in iOS is incorrect.
Closes https://github.com/facebook/react-native/pull/13755
Differential Revision: D4994048
Pulled By: javache
fbshipit-source-id: 9ec2f793f03f529e9cf0f89106f88445fde50f2a
Summary: People rarely re-order sections so this is an annoying requirement and we can just use the index by default.
Reviewed By: thechefchen
Differential Revision: D4972154
fbshipit-source-id: 256c445b36c9ba101277614d30a6dc1dbd477ee0
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02
Summary:
I don't think editing the search path is necessary anymore for notifications since [0.40](https://github.com/facebook/react-native/releases/tag/v0.40.0).
I removed the part that says to edit the search paths, and changed `#import "RCTPushNotificationManager.h"` to `#import <React/RCTPushNotificationManager.h>` in the documentation
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13700
Differential Revision: D4969728
Pulled By: javache
fbshipit-source-id: d72aee1c5b8578cea27d6b7d45ee7a7f269433fc
Summary:
In the current docs, it's not quite clear, at the first sight, what the `lang` parameter passed to `onValueChange` is. This makes it obvious.
Closes https://github.com/facebook/react-native/pull/13617
Differential Revision: D4969592
Pulled By: javache
fbshipit-source-id: e94bedefebbe19d838d010f0c79d9a76743a4341
Summary:
What existing problem does the pull request solve?
I was seeing errors in the crash monitoring software for my app in production. Many took the form of, `Unable to open URL: telprompt:5551231234`
After some research, I found that when the user attempts to call a phone number, a dialog pops up in iOS asking the user to confirm or cancel the call. If the call is canceled, the promise returned by `openURL` is rejected.
This PR improves the documentation around what happens to the promise returned by `openURL`.
No test plan, text changes only.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13624
Differential Revision: D4962161
Pulled By: javache
fbshipit-source-id: c8d5ffbc24ba4c14c85db6ea799a6f95339b94c8
Summary:
Looking to address a few new `FlowFixMe`s I had to do some minor refactoring of `MessageQueue`. Has the advantage of (IMO) making things clearer by removing a redundant counter and some gratuitous bitwise operations.
Previously `_callbacks` was an array of `?Function`s where even elements were failure callbacks and odd elements were successes. Each new call incremented `_callID` by one and `_callbackID` by two. I've changed this to use two arrays `_successCallbacks` and `_failureCallbacks` indexed by `callID`. That made the `_callbackID` counter unnecessary and reduced the need for computed indices.
Tested with flow and a quick play with UIExplorer.
Closes https://github.com/facebook/react-native/pull/11986
Differential Revision: D4962162
Pulled By: javache
fbshipit-source-id: 17dddfedc0cb5950dbdd9bd06fae6eb6de4c4a7d
James Isaac
Matt Mahoney
Reem Helou
Jean Regisser
Neo
Janic Duplessis
Gabe Levi
Adam Perry
Johan
Aaron Chiu
Arsen Ghazaryan
Spencer Ahrens
cailenmusselman
Pieter De Baets
Alexey Lang
Dan Abramov
Valentin Shergin
Jiajie Zhu
Eric Vicenti
liushigit
Pieter De Baets
Fred Liu
Emily Janzer
Brian Vaughn
Louis Lagrange
Andres Suarez
周中原
Jeff Case
janus_wel
Sokovikov
Blair Vanderhoof
Jan Kassens
Karin Wefald
Brendan Rius
Vojtech Novak
Garrett McCullough
rh389
