Summary:
After taking a look at the existing animation docs, I found that most of the documentation on using `Animated` was spread out throughout the Animations guide and the `Animated` API reference, without any particular structure in place.
This PR aims to clean up the API reference, focusing on documenting all the provided methods exhaustively, and deferring to the Animations guide for long form examples and supporting content.
The `Easing` module is referred to at various points in the API reference, so I decided to clean up this doc as well. easings.net provides some handy visualizations that should make it easier for the reader to understand what sort of easing curve each method provides.
The site was built locally, and I verified all three documents render correctly.
Closes https://github.com/facebook/react-native/pull/12410
Differential Revision: D4581314
Pulled By: hramos
fbshipit-source-id: 27c0bce2afac8f084311b9d6113a2641133b42e5
Summary:
This should fix the failing ImageSnapshotTest that was added to the IntegrationTests for iOS and tvOS.
Closes https://github.com/facebook/react-native/pull/12391
Differential Revision: D4578345
Pulled By: javache
fbshipit-source-id: 13ff305276c46256fcdbb9fc070a8c08cdc0dd0a
Summary:
- Properly inherit flow types from base components, including `defaultProps`
- template-ify the `Item` type as it flows from the `data` prop into `ItemComponent`
Note that for `SectionList` is is harder to do the `Item` typing because each section in the
`sections` array can have a different `Item` type, plus all the optional overrides...not sure how to
tackle that.
Reviewed By: yungsters
Differential Revision: D4557523
fbshipit-source-id: a0c5279fcdaabe6aab5fe11743a99c3715a44032
Summary: This test is failing there, so let's disable it for now.
Reviewed By: shergin
Differential Revision: D4562533
fbshipit-source-id: bf7e871bc227f870d4b7c228b41e65e725f54255
Summary:
...to reflect the modern world we live in with dynamic DPI platforms :)
Closes https://github.com/facebook/yoga/pull/375
Reviewed By: dshahidehpour
Differential Revision: D4528518
Pulled By: emilsjolander
fbshipit-source-id: e422bd4ae148e02c598a7b484a6adfa8c0e1e0c9
Summary: Makes it easy to render separators between sections, as opposed to between items.
Reviewed By: yungsters
Differential Revision: D4555707
fbshipit-source-id: 34572ab4b2c5b47db640543149fe2551c34ccf7b
Summary:
The index is used to make sure the layout corresponds to the correct index, which can get
out of sync if cell layout is cached and then cells are re-ordered.
Reviewed By: bvaughn
Differential Revision: D4554721
fbshipit-source-id: 9acb37f390a6e40ad89f813b78f81b399ec11e9a
Summary:
Simple API takes structured `sections` prop instead of `data` array. `sections` is an array of
`Section` objects, each of which has a `key` and an `itemData` array which is analogous to a
`FlatList` `data` prop, plus optional props like `ItemComponent` that can be overridden on a
per-section level, allowing heterogeneous section item rendering via clean composition.
Flattens the sections data and renders with VirtualizedList under the hood. Doesn't support
sticky headers yet.
Reviewed By: yungsters
Differential Revision: D4519354
fbshipit-source-id: 58de959dadb6f55f681245ecd99a5dc356a48f36
Summary:
We were saving the old state, so it would always be one screen away when reloading before.
Now it works the same way as android. Ideally we would factor out all this shared code...
Reviewed By: ericvicenti
Differential Revision: D4537509
fbshipit-source-id: 28ea8fd579521bd45829013364e884678af81c30
Summary: Now layout direction (LTR or LTR) can be specified not only for whole app but also for view subtree via `direction` style property.
Reviewed By: mmmulani
Differential Revision: D4510206
fbshipit-source-id: 4e56c5886b6e42f2343165eb76be897e681c5ba4
Summary:
We really need a better list view - so here it is!
Main changes from existing `ListView`:
* Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window.
* No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible.
* Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`.
* Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props.
* Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive.
* Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>`
* Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior.
* Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable.
Demo:
https://www.facebook.com/groups/576288835853049/permalink/753923058089625/
Reviewed By: yungsters
Differential Revision: D4412469
fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
Summary:
**Motivation**
Ability to customize slider colors is desirable to match the brand. Currently iOS allows using images for slider parts, but android doesn't have any customization options. This PR adds support for customizing `thumbTintColor`, `trackTintColor` and `progressTintColor`.
**Test plan (required)**
Run UIExplorer example with the changes and verify everything works fine.
cc brentvatne
Closes https://github.com/facebook/react-native/pull/11946
Differential Revision: D4427474
fbshipit-source-id: ec3a38db600bac6108691a4cfa15e2409143b9f3
Summary:
The `successCallback` passed via `static showShareActionSheetWithOptions(options, failureCallback, successCallback)` has two parameters (see [native code](e1577df1fd/Libraries/ActionSheetIOS/RCTActionSheetManager.m (L174))), and the name used for the first parameter in the JS example is confusing. This fixes that.
The first parameter is a boolean indicating whether the user completed the sharing (when TRUE) or cancelled it (when FALSE). Instead of calling it "success" in the example, I propose using `completed`, which is more in line with what you see in the native code.
Otherwise, we have a "successCallback" function whose first parameter tells us if we were "successful", and that's confusing (indeed, I think it already caused some confusion in the [react-native-share](https://github.com/EstebanFuentealba/react-native-share/) module: see [this issue](https://github.com/EstebanFuentealba/react-native-share/issues/48)).
Closes https://github.com/facebook/react-native/pull/11914
Differential Revision: D4490039
Pulled By: mkonicek
fbshipit-source-id: 5d7f01eae760e3fb271e7fa080c2f0147c53418a
Summary:
If you have a new example that you add to the UIExplorer, enter the example, but
then change the name of the example or remove it, the explorer enters a
completely broken state. It remembers the name of the last module entered and
keeps trying to enter it. Reloading, refreshing, nothing will work until you
completely reinstall the app.
This fixes this by not trying to render the current module if it doesn't exist.
It will simply skip it.
Reviewed By: yungsters
Differential Revision: D4475088
fbshipit-source-id: d4a530b235aa2712d663377e33fe65091163d262
Summary:
RecyclerViewBackedScrollView was deprecated, this removes usages in Examples as well as in NetworkOverlay.
**Test plan**
Tested that RecyclerViewBackedScrollView deprecation warning doesn't show up anymore.
Closes https://github.com/facebook/react-native/pull/11999
Differential Revision: D4443707
Pulled By: hramos
fbshipit-source-id: 087afc9f183b3f2087965a2fe84301f422e48e9c
Summary:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
Summary:
Following the PR https://github.com/facebook/react-native/pull/6195, this adds a `HEIGHT` constant on `StatusBar` for iOS.
Combined with `statusBarFrameDidChange` and `statusBarFrameWillChange` StatusBar native events, it solves various problems with In-Call cellar bar / Location bar / others 40pt status bars, and offers a correct `keyboardVerticalOffset` value for the KeyboardAvoidingView component.
Closes https://github.com/facebook/react-native/pull/12041
Differential Revision: D4450924
Pulled By: hramos
fbshipit-source-id: 664798260f4226140f3fa3f9222a415a305d0d78
Summary:
Support `xhr.send(data)` for typed arrays.
**Test plan:** run UIExplorer example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/11904
Differential Revision: D4425551
fbshipit-source-id: 065ab5873407a406ca4a831068ab138606c3361b
Summary:
Simple fix for a typo in the webview examples.
Closes https://github.com/facebook/react-native/pull/11794
Differential Revision: D4393755
fbshipit-source-id: 43939c4f6eaede51a0e3948181eb58132ba84191
Summary:
Add one more parameter which can specify the keyboard type of first text input(if exists) to AlertIOS.prompt().
Example usage:
`AlertIOS.prompt('Type a phone number', null, null, 'plain-text', undefined, 'phone-pad')`
Closes https://github.com/facebook/react-native/pull/8781
Differential Revision: D4437900
Pulled By: hramos
fbshipit-source-id: 8141cc0d7c70d13603cd5a1d5ea3f1ab1ce437a6
Summary:
In the context of an app an image exists in three resolutions on the server: `thumb` (30px) `feed` (300px) `full` (900px). When looking at an individual item a user can come either from the feed, via a permalink or from other parts of the app. This allows a situation where the `feed` image might or might not already be loaded somewhere in the app. In the detail view I want to render `thumb` with a blur (to quickly display something), then the `feed` image if it exists to have something decent to display until `full` loads. However it is quite a waste to load the `feed` image if it isn't already in cache, and will slow down the time until `full` is loaded. It is possible to track the navigation from feed->detail and that the `feed` image has actually completed loading by the feed component however as component hierarchies grow this turns into quite a lot of prop passing and bad separation of concerns.
NSURLRequests accepts a [Cache Policy](https://developer.apple.com/reference/fo
Closes https://github.com/facebook/react-native/pull/10844
Differential Revision: D4425959
Pulled By: lacker
fbshipit-source-id: 679835439c761a2fc894f56eb6d744c036cf0b49
Summary:
**Motivation**
See if we can safely run a WebSocket test in Travis CI
Closes https://github.com/facebook/react-native/pull/11433
Differential Revision: D4342024
Pulled By: ericvicenti
fbshipit-source-id: 137fb0c39ed7ea3726e2778d5c0bdac4cef6ab89
Summary:
The XHRExample file had been forked between iOS and Android for various reasons that are no longer valid, making maintenance unnecessarily difficult. New features demos had in fact been added in separate files to avoid further duplication. This change continues on that same trajectory and splits the entire example file into multiple files. This makes them much easier to handle. We also get rid of the iOS/Android fork.
**Test plan:** Run UIExplorer app, specifically the XHR examples, on both iOS and Android.
Closes https://github.com/facebook/react-native/pull/11901
Differential Revision: D4419882
Pulled By: ericvicenti
fbshipit-source-id: ec12836dfa8e1b9259b92a7510914857a8db58d5
Summary:
Currently, < WebView > allows you to pass JS to execute within the view. This works great, but there currently is not a way to execute JS after the page is loaded. We needed this for our app.
We noticed that the WebView had messaging support added (see #9762) . Initially, this seemed like more than enough functionality for our use case - just write a function that's injected on initial load that accepts a message with JS, and `eval()` it. However, this broke once we realized that Content Security Policy can block the use of eval on pages. The native methods iOS provide to inject JS allow you to inject JS without CSP interfering. So, we just wrapped the native methods on iOS (and later Android) and it worked for our use case. The method injectJavaScript was born.
Now, after I wrote this code, I realized that #8798 exists and hadn't been merged because of a lack of tests. I commend what was done in #8798 as it sorely solves a problem (injecting JS after the initial load) and has more features than what I'
Closes https://github.com/facebook/react-native/pull/11358
Differential Revision: D4390425
fbshipit-source-id: 02813127f8cf60fd84229cb26eeea7f8922d03b3
Summary:
updated this.state to reflect the different date type options in the DatePickerAndroid components.
Closes https://github.com/facebook/react-native/pull/11600
Differential Revision: D4376621
Pulled By: ericvicenti
fbshipit-source-id: 6802d346c200870e9b3de766c9e575c7d9f7e6df
Summary:
Adds the feature to use percentage as a value unit.
You can use the function ```YGPx(float)``` and ```YGPercent(float)``` for convenience.
I did some benchmarks:
```
Without Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.146683 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.490101 ms
Huge nested layout: median: 23.000000 ms, stddev: 0.928291 ms
Stack with flex: median: 0.000000 ms, stddev: 0.170587 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.143384 ms
Nested flex: median: 0.000000 ms, stddev: 0.477791 ms
Huge nested layout: median: 22.000000 ms, stddev: 2.129779 ms
With Percentage Feature - Release x86:
Stack with flex: median: 0.000000 ms, stddev: 0.132951 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.489570 ms
Huge nested layout: median: 21.000000 ms, stddev: 1.390476 ms
Closes https://github.com/facebook/yoga/pull/258
Reviewed By: dshahidehpour
Differential Revision: D4361945
Pulled By: emilsjolander
fbshipit-source-id: a8f5bc63ad352eb9410d792729e56664468cd76a
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:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Mathieu Baudet
Hector Ramos
dlowder-salesforce
Spencer Ahrens
Mehdi Mulani
David Hart
Valentin Shergin
Sokovikov
Satyajit Sahoo
Bhuwan Khattar
Marc Horowitz
Peter W
Andrei Coman
Janic Duplessis
Martin Konicek
Ryan Gomba
Pieter De Baets
Mathieu Acthernoene
Philipp von Weitershausen
Luke Miles
Fred Liu
yueshuaijie
Peter Salanki
Michael Lee
Emil Sjolander
Buchi Anora
Lukas Woehrl
Maxime Lapointe
