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 section on changing ports is missing a key step for folks wishing to run on device
What existing problem does the pull request solve?
Changing packager port to something other than 8081 also requires the react native xcode project file to be updated in order to be able to build and run on device. The section on changing ports currently does not address this. See https://github.com/facebook/react-native/issues/10715#issuecomment-258082512.
Documentation update, no tests required.
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/14293
Differential Revision: D5647393
Pulled By: hramos
fbshipit-source-id: 040c3edea7d25c0efe560d5df30e86e1f26355bc
Summary:
This is a workaround for missing PDF url support in Android WebView, which is a general known issue: when tapping a PDF url within WebView, instead of doing nothing, we just let android default intent handle it (e.g. it will open Chrome to load it).
This is basically to trick `shouldOverrideUrlLoading()` to return true for the specific url. The drawback is that product code needs to provide the whitelist.
The proper fix would be to use PdfRenderer in that method, but it seems like it's only for API >= 21...
Differential Revision: D5619383
fbshipit-source-id: f86b930f970dab9a5f57999df69ce94b9508edc9
Summary:
Since the `hot` parameter is not used anymore in metro-bundler (we are always applying the HMR transforms for bundlers requested through the HTTP server), we can remove it from the client request URL.
This allows us to reduce the metro-bundler memory by half when switching between HMR and not-HMR, since metro caches the bundles based on the requested URL path.
Reviewed By: davidaurelio
Differential Revision: D5630051
fbshipit-source-id: fb5dce4c31bbb38b1c0c93c97a525a992b2f6d8d
Summary:
(This diff was decoupled from D4983054 which landing was quite delayed.)
`RCTUnsafeExecuteOnMainQueueOnceSync()` synchronously executes a block once, on main queue.
I found that our old implementation of `RCTScreenScale()` causes deadlock when it is called from main and background thread simultaneously.
After I implemented my own solution I googled this issue and found an article by Ben Alpert with this awesome helper:
https://benalpert.com/2014/04/02/dispatch-once-initialization-on-the-main-thread.html
So, I found it super useful and borrowed it.
Hey spicyj! :)
Reviewed By: fkgozali
Differential Revision: D5632592
fbshipit-source-id: dff43a5780b7404a3cc109c66c131cef4f4df429
Summary:
We ran into a couple of problems with the implementation of `getCurrentPosition` on Android:
- It sometimes returns an inaccurate location
- It times out when `enableHighAccuracy` is `true` (#7495)
This change improves `getCurrentPosition` for both of the above problems. Instead of calling `requestSingleUpdate` it now calls `requestLocationUpdates` so it can receive multiple locations giving it an opportunity to pick a better one. Unlike `requestSingleUpdate`, this approach doesn't seem to timeout when `enableHighAccuracy` is `true`.
**Test plan (required)**
Verified in a test app that `getCurrentPosition` returns a good location and doesn't timeout when `enableHighAccuracy` is `true`. Also, my team has been using this change in our app in production.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15094
Differential Revision: D5632100
Pulled By: hramos
fbshipit-source-id: 86e40b01d941a13820cb775bccad7e19dba3d692
Summary:
Allows us to parse the `import()` syntax. For now it's not transformed, so it would crash at runtime (or at minification with UglifyJS). However I want to release this under a new major version, so this wouldn't be allowed in OSS right away.
Also we bump to version 3.0.0 before release. D5443966 possibly introduced breaking changes, so it needs a major bump.
Reviewed By: cpojer
Differential Revision: D5630084
fbshipit-source-id: b271bbb8577ba7184e975f996ec415a915e869d9
Summary:
Flow syntax is wrong, instead of using `Array` author used syntax for [tuples](https://flow.org/en/docs/types/tuples/). Tested with flow 0.49.1.
1. Import `removeDeliveredNotifications` in your code and pass an array with more than one element.
2. Test with flow.
Closes https://github.com/facebook/react-native/pull/15490
Differential Revision: D5622949
Pulled By: ericnakagawa
fbshipit-source-id: f9ed35a178eebac1b26a6ec15c66dc14331f7d34
Summary:
This shows progress for the download of the JS bundle (different from the packager transform progress that we show already). This is useful especially when loading the JS bundle from a remote source or when developing on device (on simulator + localhost it pretty much just downloads instantly). This will be nice for the expo client since all bundles are loaded over the network and can take several seconds to load.
This depends on https://github.com/facebook/metro-bundler/pull/28 to work but won't crash or anything without it, it just won't show the progress percentage.
**Test plan**
Tested that bundle download progress is shown properly in RNTester on both localhost + simulator and on real device with network conditionner to simulate a slow loading bundle.
Tested that it doesn't cause issues if the packager doesn't send the Content-Length header.
Closes https://github.com/facebook/react-native/pull/15066
Differential Revision: D5449073
Pulled By: shergin
fbshipit-source-id: 43a8fb559393bbdc04f77916500e21898695bac5
Summary: Allows to use `setupBabel.buildRegExps` with regular expressions, not only with strings.
Reviewed By: mjesun
Differential Revision: D5614738
fbshipit-source-id: ccad4d49f8d2006a714833989b3c6be2ce7071ab
Summary:
This diff builds on top of the refactor to use `async/await` and adds multi-client support to Hot Module Reloading.
Thanks to async/await it's been quite straightforward to add this logic, since the only thing that I've had to do is to create a `Set` with the currently connected clients and passed the specified client to each method that was using the global client before.
This closes https://github.com/facebook/react-native/issues/14334
Reviewed By: davidaurelio
Differential Revision: D5611176
fbshipit-source-id: ec29438887342877c372b61132efada16af58fa5
Summary:
This is a simple groundwork PR to allow options to be passed to the `WebSocket` constructor. It represents a minor change to an undocumented part of the API, moving `headers` to within `options`.
This will be a BC for anyone manually specifying headers other than `origin` but a) that's not a common use case with WebSockets and b) it's not documented even in code and wouldn't currently pass a flow check.
NB: The third argument to the WebSocket constructor isn't part of the W3C spec, so I think this is a good place for RN-specific named parameters, better than adding a fourth argument. `protocols` needs to stay where it is, in line with the spec.
If this goes through I'd like to build on it by adding an additional connection option for SSL certificate pinning, as already supported by the underlying `okhttp` and `RCTSRWebSocket`. It could later be expanded for various other uses.
Currently, there's no way for a `WebSocket` user to specify any connection options other than url, protocol and headers. The fact that `WebSocket` connects in its constructor means any options have to go in there.
Connect to a websocket server using iOS and Android, observe the connection headers:
1. Without specifying `origin`, the default header should be set
2. Specifying it in the old way `new WebSocket(url, protocols, { origin: 'customorigin.com' })`
3. Specifying it in the new way `new WebSocket(url, protocols, { headers: { origin: 'customorigin.com' }})`.
I've tested myself using the test app with iOS and Android.
Closes https://github.com/facebook/react-native/pull/15334
Differential Revision: D5601675
Pulled By: javache
fbshipit-source-id: 5959d03a3e1d269b2c6775f3e0cf071ff08617bf
George Jose
Kevin Gozali
Marc Horowitz
Jaych Su
Nicolas Charpentier
Sriram Ramasubramanian
Phạm Huy Hoàng
Jodi Warren
Rafael Oleza
Jean Lauliac
Eric Rozell
Valentin Shergin
Slava Kim
Adam Comella
Nivetha Singara Vadivelu
David Vacca
Ben Nham
Alexey Lang
Aaron Chiu
Andrew Y. Chen
Radek Czemerys
Janic Duplessis
David Aurelio
Paco Estevez Garcia
Kathy Gray
Alex Dvornikov
Charles Dick
Dmitry Zakharov
Summer Kitahara
Riley Dulin
Michael Lee
Miguel Jimenez Esun
Rob Hogan
