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.
![img_05070155d2cc-1](https://user-images.githubusercontent.com/2677334/28293828-2c08d974-6b24-11e7-9334-e106ef3326d9.jpeg)
**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
Summary:
**Motivation**
Fix flickering in TabBarIOS on Apple TV... issue #15081
After this change, on Apple TV, TabBarIOS item selections will be controlled purely from the native side after initial render with the `selected` prop. This is necessary because the `UITabBar` implementation in tvOS moves the selection before calling `shouldSelectViewController:`; this issue does not occur on iOS.
**Test plan**
Existing CI should still pass. Issue is resolved when testing the example code in #15081 .
Closes https://github.com/facebook/react-native/pull/15220
Differential Revision: D5601671
Pulled By: javache
fbshipit-source-id: c18e7d3482d6c07d534ff40a443a6f642d4267bb
Summary:
When you have a numeric non-multiline `TextInput` and a `returnKeyType` is `done` we automatically add an input accessory view ([implementation](603cc48ceb/Libraries/Text/RCTTextInput.m (L269)#L315)).
That view has a done button which triggers [handleInputAccessoryDoneButton](603cc48ceb/Libraries/Text/RCTTextInput.m (L317...L320)) which currently directly sends `endEditing:` to the text field / text view. As a consequence, the [textInputShouldReturn](603cc48ceb/Libraries/Text/RCTTextInput.m (L118...L121)) is not called and we dismiss the keyboard even if the `blurOnSubmit` value is `false`.
Confirm that the keyboard is not dismissed when you tap on Done button on this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit={false}
/>
```
and that the keyboard is dismissed for this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit
/>
```
Closes https://github.com/facebook/react-native/pull/15438
Differential Revision: D5601462
Pulled By: javache
fbshipit-source-id: 24e4048e2e66d1a42fa97d83b4a3eb61e5d817ea