Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: CI_USE_PACKAGER flag was set only for testing, not running.
Reviewed By: nathanajah
Differential Revision: D3334982
fbshipit-source-id: 3f98e697bd144a4ac6d8d7cfabf546bb55de1695
Summary:
Hey,
I've created a PR a few weeks ago #7264. It got merged in and then I received some emails and got mentioned in a few issues that it doesn't use renderAsOriginal prop on selectedIcon. Instead the app would use tint color.
The problem can be seen here #7467.
I've now added a method in TabBarItem that sets selectedIcon to renderAsOriginal if the prop is set.
I added a "relay" icon to UIExplorer TabBarIOS example so you can see the item is now rendered in color as the image supplied.
Oh and also should this PR be made from master. Had to work on this issue from 0.27 because the master was broken for me.
Closes https://github.com/facebook/react-native/pull/7709
Differential Revision: D3339795
fbshipit-source-id: d8d4699bb617ecae8996a6627f3774c6473c19e0
Summary:
The refactor work (renamed `navigationState.children` to `navigationState.routes`) from D3333735
broken UI Explorer in Android. Fix it.
Reviewed By: ericvicenti
Differential Revision: D3334014
fbshipit-source-id: 345fbb5eabc792a49c6f2f82ce8c03679bc75940
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
[Experimental API breaking changes]
The notion of `parent` or `children` in navigaton is misleading. We have no intention to maintain or
build the nested or hierarchical navigation states. To be clear, rename `navigationState.children` to
`navigationState.route`.
Reviewed By: ericvicenti
Differential Revision: D3332115
fbshipit-source-id: c72ed08acaf030fb9c60abf22fb15cc0f44b3485
Summary:
[public / experimental API breaking change]
The data type of `scene.navigationState` is `NavigationRoute`. Rename `scene.navigationState` to
`scene.route` to avoid confusion such as treating `scene.navigationState` as the actual global navigation
state (type: NavigationState).
Reviewed By: ericvicenti
Differential Revision: D3331076
fbshipit-source-id: 3ed989cc8492d398cbeb1b12186459deb261d1fb
Summary:
This is the first step to clarify and simplify the type definations about navigation state.
For now, `NavigationParentState` is actually used as the real navigation state and `NavigationState` is used
as a route in navigation, which has been confusion among the APIs.
To be clear, our APIs has no intention and interest in dealing with nested or hierarchical navigation states,
and we should avoid have the name like `ParentState` or `children`.
To fully migrate the types, theer will be a lot of code changes and this is just the first step to rename.
= What's Next?
1. rename `navigationState.children` to `navigationState.routes` (breaking change!)
2. remove `navigationState.key` from its type defination.
Reviewed By: ericvicenti
Differential Revision: D3321403
fbshipit-source-id: 3e39b60f736c1135bc85d8bf2b89027d665e28d4
Summary:
It seems like the examples weren't working since the merge of `IntentAndroid` and `LinkingIOS` since they were still using `TouchableNativeFeedback` only available on Android.
The problem was also reported here : https://github.com/facebook/react-native/issues/7615
Closes https://github.com/facebook/react-native/pull/7655
Differential Revision: D3329233
fbshipit-source-id: 8c9cabaab0a616dab406c4e444c9fa6da5f54b6d
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary:
= Breaking Change (for experimental features) =
<NavigationView /> serves no obvious benefit and it's costly to maintain it.
- its features could be completely replaced by NavigationAnimatedView without
enabling the transtion animation.
- it could also be replaced with a simple view and normal scene renderer.
Reviewed By: ericvicenti
Differential Revision: D3280547
fbshipit-source-id: 4ac3dbe92ceb9107a1f6e77a78bd6021485e78a9
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.
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.
Or change it to yellow for demonstrating purposes
.
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.
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
Summary:Previously, (mostly touch and scroll) event handling on iOS worked in a hybrid way:
* All incoming coalesce-able events would be pooled and retrieved by js thread in the beginning of its frame (all of this happens on js thread)
* Any non-coalesce-able event would be immediately dispatched on a js thread (triggered from main thread), and if there would be pooled coalesce-able events they would be immediately dispatched at first too.
This behavior has a subtle race condition, where two events are produced (on MT) in one order and received in js in different order.
See https://github.com/facebook/react-native/issues/5246#issuecomment-198326673 for further explanation of this case.
The new event handling is (afaik) what Android already does. When an event comes we add it into a pool of events and dispatch a block on js thread to inform js there are events to be processed. We keep track of whether we did so, so there is at most one of these blocks waiting to be processed. When the block is executed js will process all events that are in pool at that time (NOT at time of enqueuing the block).
This creates a single way of processing events and makes it impossible to process them in different order in js.
The tricky part was making sure we don't coalesce events across gestures/different scrolls. Before this was achieved by knowing that gestures and scrolls start/end with non-coalesce-able event, so the pool never contained events that shouldn't be coalesced together. That "assumption" doesn't hold now.
I've re-added `coalescingKey` and made touch and scroll events use it to prevent coalescing events of the same type that should remain separate in previous diffs (see dependencies).
On top of it it decreases latency in events processing in case where we get only coalesce-able events. Previously these would be processed at begging of the next js frame, even when js would be free and could process them sooner. This delay is done, since they would get processed as soon as the enqueued block would run.
To illustrate this improvement let's look at these two systraces.
Before: https://cloud.githubusercontent.com/assets/713625/14021417/47b35b7a-f1d3-11e5-93dd-4363edfa1923.png
After: https://cloud.githubusercontent.com/assets/713625/14021415/4798582a-f1d3-11e5-8715-425596e0781c.png
Reviewed By: javache
Differential Revision: D3092867
fb-gh-sync-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
fbshipit-source-id: 29071780f00fcddb0b1886a46caabdb3da1d5d84
Summary: This was previously removed in D2884587, but we will need it going forward. See D3092867 for reasons why it's necessary again.
Reviewed By: javache
Differential Revision: D3092848
fb-gh-sync-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
fbshipit-source-id: 0d10dbac4148fcc8e035d32d8eab50f876d99e88
Summary:The navigation drawer of most apps on android opens over the status bar, this adds an option to do so. It implements a similar API to the native DrawerLayout by adding a statusBarBackgroundColor to DrawerLayoutAndroid.
Without statusBarBackgroundColor:
With statusBarBackgroundColor:
This PR depends on the changes in #6195 to add the `StatusBar.HEIGHT` constant I just want to put it out there now to see if this looks good. To test without the other PR just change `StatusBar.HEIGHT` for `25`.
It is implemented by making the native status bar translucent and making its background color transparent so we can draw a view of the same height as the status bar under it as a child of the DrawerLayoutAndroid. Then we can draw a semi-transparent gray View inside the drawer view to make it
Closes https://github.com/facebook/react-native/pull/6218
Differential Revision: D3017444
Pulled By: bestander
fb-gh-sync-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
fbshipit-source-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
Summary:This address the issue reported at
https://github.com/facebook/react-native/issues/6579#issuecomment-200984628
NavigationView should have the same API as NavigationAnimatedView does except
that NavigationView does not need the APIs for animation.
This unify the API of our core components so that people can freely
compose views with both NavigationAnimatedView or NavigationView.
Reviewed By: fkgozali
Differential Revision: D3096076
fb-gh-sync-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
fbshipit-source-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
Summary:Update CameraRoll examples to use promises because callbacks are deprecated.
Closes https://github.com/facebook/react-native/pull/6681
Differential Revision: D3102981
fb-gh-sync-id: c37bc2e470b7cb2aa4a9b3b21d76ddeb9cf3b71c
fbshipit-source-id: c37bc2e470b7cb2aa4a9b3b21d76ddeb9cf3b71c
Summary:- All the public sub component renderers should implement the interface
NavigationSceneRenderer, which will help to reuse renderer or
replace renders for different composition.
- Perf improvement. <NavigationHeader /> is rendering way more
sub component than necessary, we shall fix that.
- No UI or behavior change.
Reviewed By: ericvicenti
Differential Revision: D3091442
fb-gh-sync-id: fba5f7ce74597fa6036b5b216c02b06052801983
shipit-source-id: fba5f7ce74597fa6036b5b216c02b06052801983
Summary:sometimes it is nessesary to handle back button
specifically for component, by changing its state.
For ex. exit from edit mode.
Closes https://github.com/facebook/react-native/pull/5062
Differential Revision: D3084590
Pulled By: ericvicenti
fb-gh-sync-id: 13a4ea1d64ce725daa5d3af0d629a0c132a3f3d5
shipit-source-id: 13a4ea1d64ce725daa5d3af0d629a0c132a3f3d5
Summary:Add ability to specify custom left, right components, and title component. Style the `NavigationBar` according to the Platform.
Refer https://github.com/ericvicenti/navigation-rfc/pull/21
cc ericvicenti
Closes https://github.com/facebook/react-native/pull/5971
Differential Revision: D3080601
Pulled By: ericvicenti
fb-gh-sync-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
shipit-source-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary:This adds a `HEIGHT` constant on `StatusBar` on Android. I needed only this for now but I will work on a better status bar dimensions API later (see TODO).
It also improves the implementation to fix a bug that happened when multiple `StatusBar` components get updated in the same frame as well as remove useless calls to the `StatusBarModule` when values did not change.
Instead of calling the `StatusBarManager` immediately when the component gets updated and relying on the order of the calls that get dispatched to native we now wait at the end of the frame to send the calls to the `StatusBarManager` using `setImmediate`. To make this work properly we need to change the data structure of the props stack a little bit to store the desired transition/animation too for each value.
Finally this updates the example to only show the ones that work for the current platform.
**Test plan**
In the UIExplorer Example, in the 'StatusBar dimensions' section it should show 25 for the height of the status bar.
A
Closes https://github.com/facebook/react-native/pull/6195
Differential Revision: D3017559
fb-gh-sync-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
shipit-source-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
Summary: Port the legendary props `onWillFocus` and `onDidFocus` from `Navigator` to `NavigationLegacyNavigatorRouteStack`.
Reviewed By: fkgozali
Differential Revision: D3063530
fb-gh-sync-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
shipit-source-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
Summary:Per offline discussion with ericvicenti, we'd like to reudce the complexity by
keeping <NavigationCard /> nothing more than just a simple `<Animated.View />`,
which helps us to avoid over generalize the styles, gestures of what the Navigation card
needs to be.
The proposalis to use the same props (NavigationSceneRendererProps) that is used to render
the scene to generate the style and pan handlers needed for the navigation card.
No behavior changes, just implementation details clean up work.
Reviewed By: ericvicenti
Differential Revision: D3037225
fb-gh-sync-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
shipit-source-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
Summary:Adds a test so that people can create RCTBridgeModules that aren't auto-exported. This is useful for when you have more than one RCTBridge and want a module to be exposed in one but not the other.
RCTBridge/RCTBatchedBridge already supports this functionality; this diff adds a test so that it doesn't break.
Closes https://github.com/facebook/react-native/pull/6424
Differential Revision: D3044959
Pulled By: nicklockwood
fb-gh-sync-id: f8977249b1bf4023e704be6422ad77372d8f1714
shipit-source-id: f8977249b1bf4023e704be6422ad77372d8f1714
Summary:Removed eslint rule that checks modules
After we updated to ESLint 2.x, ESLint started complaining `'use strict' is unnecessary inside of modules strict`.
This is correct behaviour because according to spec modules are strict.
The problem is that our transforms don't transpile strict mode so we still need to have this pragma in all our code.
I did not find a way to make eslint require "use strict" for ES6 modules: https://github.com/eslint/eslint/issues/2785
So I am removing this.
What stops us from automatically adding strict mode with babel?
Need your feedback, frantic martinbigio
David said that you Martin looked into this.
Closes https://github.com/facebook/react-native/pull/6403
Differential Revision: D3038039
Pulled By: martinbigio
fb-gh-sync-id: b8a00c093768a318487dcb89e433859825a08b2c
shipit-source-id: b8a00c093768a318487dcb89e433859825a08b2c
Summary:Given that you can do all kinds of animations other than `Animated.timing`, it made no sense to have `setTiming`. In addition, you can't intuitively tell that this is the callback where you would do custom animations.
The discussion took place on Discord with ericvicenti: https://discordapp.com/channels/102860784329052160/154015578669973504
Closes https://github.com/facebook/react-native/pull/6235
Differential Revision: D2999121
Pulled By: hedgerwang
fb-gh-sync-id: f587b865de11ba5e8dc9c430720252ffb5d12794
shipit-source-id: f587b865de11ba5e8dc9c430720252ffb5d12794
Summary:Motivation: After second navigation event in UIExplorer, content in main page always stayed the same.
Fix: For second and future navigation events use stack.index to retrieve state from stack.children.
Closes https://github.com/facebook/react-native/pull/6312
Differential Revision: D3018119
Pulled By: andreicoman11
fb-gh-sync-id: 4c502c42a0cb7b240e558515fb8fd766d6e1f856
shipit-source-id: 4c502c42a0cb7b240e558515fb8fd766d6e1f856
Konstantin Raev
Nick Lockwood
Urban Cvek
Hedger Wang
Nathan Azaria
Nicolas Charpentier
Corné Dorrestijn
Jimmy Mayoukou
Adam Comella
Pieter De Baets
Kevin Johnson
Eric Vicenti
Sokovikov
Christine Abernathy
Chris Geirman
Jesse Sessler
Bruno Barbieri
Christoph Pojer
Alexander Blom
Janic Duplessis
Nick Smith ♞
Jeff Chien
Mike Grabowski
James Ide
Sebastian Markbage
Alexey Lang
Tanguy Antoine
Philipp von Weitershausen
Gant
Skotch Vail
grgmo
Tomas Roos
Alexsander Akers
James Ide
Maxi Ferreira
Andrei Coman
Felix Oghina
Nick
Martin Konicek
Martin Kralik
Luqmaan Dawoodjee
Alex Kotliarskyi
Andy Street
Aleksei Androsov
Satyajit Sahoo
Alon Schwarz
Dave Miller
Richard Lai
Jeff Morrison
Corentin Smith
Michal Kulinski
Frank Yan
