Summary:
The containers in NavigationExperimental are not appropraite because the state should be held by the app's architecture, be it redux, flux, or simple component state.
This diff moves the examples over to simple component state, but there are several other examples of how to use NavigationAnimatedView and the navigation reducers with redux:
- https://github.com/jlyman/RN-NavigationExperimental-Redux-Example
- Switching the f8 app with redux to navigation experimental: https://github.com/fbsamples/f8app/pull/14
Reviewed By: hedgerwang
Differential Revision: D3219911
fb-gh-sync-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
fbshipit-source-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
Summary:
This should simplify the renderScene usage a bit because the react key is required and this will make sure they are rendered with the right key automatically.
It changes the string to make sure people do not rely on this API for anything else.
Reviewed By: javache
Differential Revision: D3033933
fb-gh-sync-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
fbshipit-source-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
Summary:
NavigationLegacyNavigator was originally created to help people to migrate to the new
navigation library without API changes. Therefore we'd have to port all the old APIs that
don't necessarily seem align well with the new navigation library.
Consider the production usage of NavigationLegacyNavigator does not exist, it's better
to kill it and we'd just rename the `Navigator` to `NavigatorDeprecated` later instead.
Reviewed By: ericvicenti
Differential Revision: D3263704
fb-gh-sync-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
fbshipit-source-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
> From the existing documentation, it's not clear how one would make use of the highlightRow attribute of ListView.renderRow. Special thanks to halilb for his assistance.
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.
> Here's a screenshot of the UIExplorer with a row highlighted (using the FB Blue Color)
> <img width="466" alt="2016-03-16_1944" src="https://cloud.githubusercontent.com/assets/1640318/13835020/49b5b38c-ebb1-11e5-98fa-17201fd3db92.png">
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/CONTRIBUTIN
Closes https://github.com/facebook/react-native/pull/6495
Differential Revision: D3264092
Pulled By: nicklockwood
fb-gh-sync-id: 9608e8a66387f527b872928a3595ca4d17736b82
fbshipit-source-id: 9608e8a66387f527b872928a3595ca4d17736b82
Summary: This adds a new SceneView with a shouldComponentUpdate policy of only re-rendering when the scene's state changes. This allows avoidance of extra re-renders. Results in a much smoother back-swipe gesture because we no longer re-render scenes as we transition from gesture to animation.
Reviewed By: hedgerwang
Differential Revision: D3219545
fb-gh-sync-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
fbshipit-source-id: 7c04e0e4ebb40d1e57ef7af11e2e54adf4f52aa0
Summary:
Previously, if a module implemented `setBridge:` we assumed that it needs to be initialised on the main thread. This assumption was not really warranted however, and it was a barrier to deferring module initialization.
This diff tweaks the rules so that only modules that override `init` or `constantsToExport**` are assumed to require main thread initialization, and others can be created lazily when they are first used.
WARNING: this will be a breaking change to any 3rd party modules that are assuming `setBridge:` is called on the main thread. Those modules should be rewritten to move any code that requires the main thread into `init` or `constantsToExport` instead.
`**` We will also be examining whether `constantsToExport` can be done lazily, but for now any module that uses it will still be created eagerly when the bridge starts up.
Reviewed By: javache
Differential Revision: D3240682
fb-gh-sync-id: 48f309e3158bbccb52141032baf70def3e609371
fbshipit-source-id: 48f309e3158bbccb52141032baf70def3e609371
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
![simulator screen shot 27 apr 2016 21 58 40](https://cloud.githubusercontent.com/assets/12081272/14866402/e51c7120-0cc3-11e6-9570-097b686c160f.png)
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
![simulator screen shot 27 apr 2016 21 59 06](https://cloud.githubusercontent.com/assets/12081272/14866419/f77aa7e2-0cc3-11e6-8c90-33209009bc09.png)
Or change it to yellow for demonstrating purposes
![simulator screen shot 27 apr 2016 21 59 13](https://cloud.githubusercontent.com/assets/1208
Closes https://github.com/facebook/react-native/pull/7264
Differential Revision: D3240924
Pulled By: nicklockwood
fb-gh-sync-id: 14a0de28abd064756320b7a74f128c255caa6b12
fbshipit-source-id: 14a0de28abd064756320b7a74f128c255caa6b12
Summary: To prevent layout popping, when inserting images inside text we would render a blank placeholder image while the real image was loading. It turns out that this isn't necessary, as we can just specify the size of the image without having an actual image to display.
Reviewed By: javache
Differential Revision: D3212766
fb-gh-sync-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
fbshipit-source-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
Summary:This adds support for delete view animations in LayoutAnimation for iOS. It supports the same properties as the create animation (alpha, scale).
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
![layout-anim2](https://cloud.githubusercontent.com/assets/2677334/14595471/86fb1654-050d-11e6-8b38-fe45cc2dcd71.gif)
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: AaaChiuuu
fb-gh-sync-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
fbshipit-source-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
Summary:Fixes #6735
On font sizes smaller than 20, iOS will swap SystemFont to SF version optimised for smaller sizes which does not have ultralight and thin. That results in ultralight and light example to be rendered with the same weight.
Bumping to `20` makes it render differently as per below screenshot https://cloud.githubusercontent.com/assets/2464966/14622260/0789e500-05c9-11e6-920a-8c948a5b79b4.png
Closes https://github.com/facebook/react-native/pull/7044
Differential Revision: D3212565
Pulled By: mkonicek
fb-gh-sync-id: 5ffad136c7f4126c271366640c89673f30a99218
fbshipit-source-id: 5ffad136c7f4126c271366640c89673f30a99218
Summary:The Obj-C tests were stalling when we updated TravisCI to use the OS X image with Xcode 7.3 and iOS 9.3.
On my own MBP with Xcode 7.3 the tests stall as well. Running `./scripts/objc-test.sh` prints out a warning near the end, which says `ld` couldn't find a Frameworks folder under the iPhoneSimulator9.3 SDK directory. Indeed, this directory doesn't exist on my computer. When creating a brand new project with unit tests and UI tests, both test targets don't specify "Framework Search Paths" so I don't think we need to specify it anymore.
Closes https://github.com/facebook/react-native/pull/7168
Differential Revision: D3216524
fb-gh-sync-id: 3097bda98d78289ecdba86801bcd461f3311ac47
fbshipit-source-id: 3097bda98d78289ecdba86801bcd461f3311ac47
Summary:We no longer forward React onto this object. We only forward the ReactNative
module onto it.
We also deprecated the addons so they'll all warn. We'll remove it
completely soon.
Closes https://github.com/facebook/react-native/pull/7136
Reviewed By: gabelevi
Differential Revision: D3211809
Pulled By: sebmarkbage
fb-gh-sync-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
fbshipit-source-id: 77aaa909dca5e2522cfaa7b4ca361fabc614be58
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: mkonicek
fb-gh-sync-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
fbshipit-source-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
Summary:This is a reprise of #6327, but with iOS 7.0 compatibility and less `package.json` changes.
**Test Plan:** Load WebSocketExample in UIExplorer app and start websocket test server script (both provided in #6889) and test sending binary data on both iOS and Android
Closes https://github.com/facebook/react-native/pull/6961
Differential Revision: D3202022
Pulled By: mkonicek
fb-gh-sync-id: 38843d0a9c0172971c5c70a5139ded04042b280a
fbshipit-source-id: 38843d0a9c0172971c5c70a5139ded04042b280a
Summary:- Get rid of no longer necessary WebSocket.js v WebSocketBase.js split
- Use `EventTarget(list, of, events)` as base class to auto-generate `oneventname` getters/setters that get invoked along with other event handlers
- Type annotation `any` considered harmful, especially when we can easily spell out the actual type
- Throw in some `const` goodness for free
**Test Plan:** Launch UIExplorer example app, supplied `websocket_test_server` script, and try different combinations of sending and receiving text and binary data on both iOS and Android.
Closes https://github.com/facebook/react-native/pull/6889
Differential Revision: D3184835
Pulled By: mkonicek
fb-gh-sync-id: f21707f4e97aa5a79847f5157e0a9f132a1a01cd
fbshipit-source-id: f21707f4e97aa5a79847f5157e0a9f132a1a01cd
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?
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).
Closes https://github.com/facebook/react-native/pull/6867
Differential Revision: D3186273
Pulled By: ericvicenti
fb-gh-sync-id: 35e82fe4389a271a30c49dd5a3bcbab7ac29a0cd
fbshipit-source-id: 35e82fe4389a271a30c49dd5a3bcbab7ac29a0cd
Summary:Currently React-Native does not have `ontimeout` and `onerror` handlers for [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest). This is an extension to [No timeout on XMLHttpRequest](https://github.com/facebook/react-native/issues/4648).
With addition to two handlers, both Android and iOS can now handle `ontimeout` if request times out and `onerror` when there is general network error.
**Test plan**
Code has been tested on both Android and iOS with [Charles](https://www.charlesproxy.com/) by setting a breakpoint on the request which fires `ontimeout` when the request waits beyond `timeout` time and `onerror` when there is network error.
**Usage**
JavaScript -
```
var request = new XMLHttpRequest();
function onLoad() {
console.log(request.status);
};
function onTimeout() {
console.log('Timeout');
};
function onError() {
console.log('General network error');
};
request.onload = onLoad;
request.ontimeout = onTimeout;
request.onerr
Closes https://github.com/facebook/react-native/pull/6841
Differential Revision: D3178859
Pulled By: lexs
fb-gh-sync-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
fbshipit-source-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
Summary:This change will change the returnKeyType to be "return" instead of being "done" since this example is trying to provide a example of a auto growing text input multiple use-case. It makes that the return key says just return in order to expand the input instead of done which does not really show the use of multiline.
Closes https://github.com/facebook/react-native/pull/6991
Differential Revision: D3184157
fb-gh-sync-id: dd0c21433009600d3cc585b941b089cab4895e7a
fbshipit-source-id: dd0c21433009600d3cc585b941b089cab4895e7a
Summary:Adds `Image.prefetch` to prefetch remote images before they are used in an actual `Image` component. This is based off of #4420 by sospartan and skevy's work.
Closes https://github.com/facebook/react-native/pull/6774
Differential Revision: D3153729
Pulled By: bestander
fb-gh-sync-id: ef61412e051a49b42ae885edce7905a8ca0da23f
fbshipit-source-id: ef61412e051a49b42ae885edce7905a8ca0da23f
Summary:This adds a BUCK file to UIExplorer to allow building it with buck. It is based on the one in the movies app but I removed the extra deps that were not needed in both files.
Also add build version number and target sdk version in the Android manifest so Buck can use it since it was only specified in the gradle build and caused the app to run on a super old target sdk.
bestander mkonicek Would it be simple to also build the ndk part with Buck? Right now it is built with gradle and packaged after. I suppose it is already being done internally at facebook. The BUCK files for building the cpp code are already there but I couldn't figure out what was missing to make it work :(
That is pretty much the only missing part to have first class support for building RN apps with Buck in OSS. We could eventually include BUCK files with the generated project.
**Test plan (required)**
Build and run UIExplorer and Movies examples using Buck.
Edited:
```
./gradlew ReactAndroid:packageReactNdkLibsForBuck
Closes https://github.com/facebook/react-native/pull/6399
Reviewed By: mkonicek
Differential Revision: D3042355
Pulled By: bestander
fb-gh-sync-id: 74760c7ba12d35b1853d2e3706c2ba130f9eef1c
fbshipit-source-id: 74760c7ba12d35b1853d2e3706c2ba130f9eef1c
Summary:First I searched for special cases that destructor PropTypes:
```
(?s)React\s*=\s*require\('react\-native'\).*(Children|PropTypes)[^\{\}]*\}\s*=\s*React;
```
I split them up manually.
Then I replaced the React = require('react-native') + destructuring pattern...
```
(?s)(const|var)\s+React\s*=\s*require\('react\-native'\)(.*[^\{\}]*\}\s*=\s*)React;
```
...with...
```
$1 React = require('react');
$1 ReactNative = require('react-native')$2ReactNative;
```
I used lint to figure out if I left some unnecessary imports.
Finally I grepped for just
```
React\s*=\s*require\('react\-native'\)
```
to catch any remaining patterns.
Also, `} = React.NativeModules` -> `} = ReactNative.NativeModules`.
Reviewed By: spicyj
Differential Revision: D3158991
fb-gh-sync-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
fbshipit-source-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
Summary:Update to new package split syntax + updated ReactART to a version that has
isomorphic rendering. D3154320.
Reviewed By: spicyj
Differential Revision: D3154434
fb-gh-sync-id: 7cfae5582de9040f10f5637c8c470310f42398f3
fbshipit-source-id: 7cfae5582de9040f10f5637c8c470310f42398f3
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary: Simplify and fix up a broken example
Reviewed By: hedgerwang
Differential Revision: D3137234
fb-gh-sync-id: 653086796d40a81f472274877fb890eee4b9b57b
fbshipit-source-id: 653086796d40a81f472274877fb890eee4b9b57b
Summary:Current docs show an Appetize.io example for AlertIOS doc. This pull request adds that feature across all applicable iOS and Android docs. So if a doc has an example in UIExplorer, it shows up in the top right and clicking to Play should navigate to the relevant example.
The changes here also touched NavigationExperimental to fix a typo that prevented iOS deep link from working. Code was also added to help support Android deep links but there's an outstanding issue (a race condition) around how Android deep links trigger getInitialURL in NavigationRootContainer that prevents this from fully working.
For adding the docs, a few things were done outside this pull request:
1/ Release builds for UIExplorer Android and iOS apps were uploaded to Appetize.io. The Appetize.io info (public key to run the build) is embedded in the docs.
2/ The iOS build was generated by making a few changes to get a local bundle. The current UIExplorer set up doesn't support "react-native run-ios".
Regarding the Appetize bu
Closes https://github.com/facebook/react-native/pull/6306
Differential Revision: D3129651
Pulled By: bestander
fb-gh-sync-id: d296d64db8236faa36f35484bb6b362990caf934
fbshipit-source-id: d296d64db8236faa36f35484bb6b362990caf934
Summary:D3092867 / 1d3db4c5dc caused deadlock when chrome debugging was turned on, so it was reverted as D3128586 / 144dc30661.
The reason: I was calling `[_bridge dispatchBlock:^{ [self flushEventsQueue]; } queue:RCTJSThread];` from main thread and expecting it will `dispatch_async` to another,
since a held lock was being accessed the dispatched block and was released after the dispatch.
Turns out `RCTWebSocketExecutor` (which is used when chrome debugger is turned on) executes all blocks dispatched this way to `RCTJSThread` synchronously on the main thread.
This resulted in a deadlock. The "dispatched" block was trying to acquired lock which held by the same thread in the dispatching phase.
A fix for this is pretty simple. We will release the lock before dispatching the block.
However it's not super straightforward to see this won't introduce some race condition in a case with two threads where we would end up with events not being processed.
My thinking why that shouldn't happen goes like this: We could get in a bad state if `flushEventsQueue` would run on JS thread while `sendEvent:` is running on MT.
(I don't have a specific example how, maybe it's not possible. However when I show this case is safe we know we are good.)
The way how locking is setup in this diff the only possible scenario where these two threads would execute in these methods concurrently is JS holding the lock and MT going to enqueue another block on JS thread (since that's outside of "locked" zone).
But this scenarion can never happen, since if MT is about to enqueue the block on JS thread it means there cannot be a not yet fully executed block on JS thread.
Therefore nothing bad can happen.
So this diff brings back the reverted diff and adds to it the fix for the deadlock.
Reviewed By: javache
Differential Revision: D3130375
fb-gh-sync-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
fbshipit-source-id: 885a166f2f808551d7cd4e4eb98634d26afe6a11
Summary:Fix spelling of the word letter. Was leter, now letter.
🐒
Closes https://github.com/facebook/react-native/pull/6780
Differential Revision: D3131714
fb-gh-sync-id: a368304267347211c139b09b82f6da12e8b67615
fbshipit-source-id: a368304267347211c139b09b82f6da12e8b67615