Summary:
I forgot to add new files manually to `React.xcodeproj` (it's not managed by buck).
public
Reviewed By: javache
Differential Revision: D2895546
fb-gh-sync-id: ed58e3505c269f5ed9433e94994471485adb2378
Summary:
I started working on improving the `StatusBar` API and make it work on Android. I added support for `setColor`, `setTranslucent` (the status bar is still visible but the app can draw under) and `setHidden` on Android. Looking for feedback on how to improve the API before I put more time on this :).
Right now I went for a cross platform API and functions that don't exist on a platform are just a no-op but I'm not sure it is the best choice since at the moment what is supported is very different between both platforms. I was wondering what you guys think and if it would be better off as 2 different modules.
It is also possible to port some of the features I added for Android to iOS even if there is no 'standard' way to do it. Like `setColor` could be implemented by drawing a colored view under the status bar and translucent by adding/removing some padding.
Closes https://github.com/facebook/react-native/pull/5360
Reviewed By: svcscm
Differential Revision: D2840417
Pulled By: nicklockwood
fb-gh-sync-id: 5c8d988bccf8035341f0efe27e54dd8402c18d24
Summary:
public
This adds support to set the highlight color on TextInput on Android. See https://github.com/facebook/react-native/pull/5678 for the iOS implementation.
Note : We will merge these two properties with one name 'selectionColor' in a follow on diff, and may move it to a style.
Reviewed By: nicklockwood
Differential Revision: D2895253
fb-gh-sync-id: 6f2c08c812ff0028973185356a8af285f7dd7969
Summary:
This is a final diff in the stack, which makes us not send a bazillion events to js after it's been busy while an user dragged his finger on a screen (resulting in ~two events per frame).
I made "touchMove" event to be coalescable, which makes us not send anything while dragging (since this makes both scroll events and touch move events coalesced and not being send until either next js frame or the next different touch event occurs).
This change is far from perfect. The event name is a hard coded string and the coalescing works with some (reasonable) assumptions on internal structure of these touch events. Which may or may not be really true. It would be great if someone could comment on these.
I'm thinking about making the touches more strongly typed. Any thoughts on this?
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884595
fb-gh-sync-id: f3c2f13430679e2bf52e0c7a3689650b3acae42f
Summary:
This diff finally makes touch events to be emitted to js from the same object as scroll events. Thanks to changes in previous diffs this means the js will now process them in the right order.
This diff on its own would cause us to send events to js on every frame while dragging a finger on the screen. This is something we tried to avoid with event coalescing in the past, and gets fixed in the following diff D2884595.
public
___
**This diff is part of a larger stack. This is a high level overview about what’s going on here.**
This stack of diffs fixes an issue where scroll events and touch events wouldn’t be processed in the correct order on js side.
Current state of world:
* touch events are send to js immediately when they happen (this makes js respond to touches as soon as possible)
* scroll events are buffered, coalesced and send at the beginning of each js frame (coalescing helps in a case where js is busy processing for several native frames and would get all scroll event for that period afterwards)
How did I change this?
1. I’ve made touch events go through the same class every other event (scroll events included) go, RCTEventDispatcher. This gives us a single place to handle all events.
2. I’ve changed RCTEventDispatcher to flush all buffered events every time it gets a touch event before dispatching the touch. This fixes the original ordering issue.
3. I’ve made “touchMove” behave the same way as scroll events do - they are buffered and coalesced. Since “touchMove” events are fired as often as scroll events (while you drag your finger around), doing only 2. would bring back the issue buffering was fixing.
All of this together effectively still keeps the order of events right, avoids overloading js in the important case we care about. The only downside is an increased latency for “touchMove” events, since they are to longer send to js immediately.
(Even better solution would be changing the native->js event passing system to be pull based instead of push based. That way js would always request touches that has happened since the last time it has asked, which would make it get them as soon as it’s possible to process them and native could do coalescing at that point.
However this change has a much bigger scope, so I’m going with this stack of diffs for now.)
Reviewed By: nicklockwood
Differential Revision: D2884593
fb-gh-sync-id: 749a4dc6256f93fde0d8733687394b080ddd4484
Summary:
This diff adds an implementation of `RCTEvent` protocol which represents touch events.
It's basically a copy of this code: c14cc123d5/React/Base/RCTTouchHandler.m (L194-L196)
which is replaced using `RCTTouchEvent` in the next diff (D2884593).
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884592
fb-gh-sync-id: e35addcf15a7012f89644200a08f5856c7f57299
Summary:
Currently only scroll events are send through `sendEvent`, and all of them are can be coalesced. In future (further in the stack) touch events will go through there as well, but they won't support coalescing.
In order to ensure js processes touch and scroll events in the same order as they were created, we will flush the coalesced events when we encounter one that cannot be coalesced.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884591
fb-gh-sync-id: a3d0e916843265ec57f16aad2f016a79764dcce8
Summary:
I want to use the `RCTEvent` protocol for touch events as well. That's why I'm removing not very well defined `body` property and replacing it with `arguments` method, which will return an array that will be passed directly to the js call.
I think this makes sense because there is no unified arguments format for all events and and the called js method (`moduleDotMethod`) is already event specific.
This way touch events and scroll events can result in calling a completely different js function with a completely different arguments (what they indeed currently do).
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884590
fb-gh-sync-id: 2c1885c3414e255d8572c0fbbbfe62a23d94dd06
Summary:
This property was never used, so I'm removing it.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: javache
Differential Revision: D2884587
fb-gh-sync-id: acd5e576cd13a02e77225f3b308232f8331d3b61
Summary:
`RCTBaseEvent` was never used. This diff removes it.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: javache
Differential Revision: D2884585
fb-gh-sync-id: 66a6afcda3b5baec7f768682da215570f6d33bb1
Summary:
public
The current `ScrollView.scrollTo()` API is confusing due to the `(y, x)` parameter order, and the boolean `animated` argument. E.g.
ScrollView.scrollTo(5, 0, true) // what do these arguments mean?
This diff replaces the API with a configuration object, so the arguments are all explicit:
ScrollView.scrollTo({x: 0, y: 5, animated: true}) // much better
The `scrollTo()` method checks the argument types, and provides backwards compatibility with the old argument format for now. Using the old API will generate a warning, and this will eventually be upgraded to an error.
Reviewed By: davidaurelio
Differential Revision: D2892287
fb-gh-sync-id: cec4d504242391267c6e863816b6180ced7a7d5e
Summary:
The bug occurs for the cases when there is a nested view structure of at least two views with removeClippedSubvews enabled and with a "collapsable" view in between them that migrates from the collapsed state to non-collapsed state.
What happens in that case is that the "inner" view with "removeClippsedSubviews" gets reattached to a new parent, but we never update it's clipping rect because the update is currently only triggered for the size change (and for scroll change in case of scrollview). In the case when the view was doing some "clipping" when attached to its previous parent it needs to update its "clipping" status because the parent has change and clipping rect is calculated based on the parent clipping rect (see `ReactClippingViewGroupHelper#calculateClippingRect`).
This change triggers `updateClippingRect` when the view is attached to the window, which covers the case when it's reattached from one parent to the other.
Closes https://github.com/facebook/react-native/pull/5692
Reviewed By: svcscm
Differential Revision: D2893304
Pulled By: foghina
fb-gh-sync-id: a94ab3674adf9e496fc86dca5a430a91117f2c83
Summary:
node-haste shouldn't ever call process.exit and should leave it up to clients to shut down properly. This change just moves it out into the `Resolver` class – I'll leave it up to David and Martin to improve error handling for the rn packager :)
public
Reviewed By: davidaurelio
Differential Revision: D2889908
fb-gh-sync-id: 6f03162c44d89e268891ef71c8db784a6f2e081d
Summary:
Right now, a mock called `debug.js` shadows a node module called `debug`. When I made mocking more strict I didn't realize that it didn't include those mocks any more because requiring `debug` would result in a module like `debug/node.js` which doesn't have a mock associated with it. This diff changes it so it looks at the associated `package.json` to match the name up to mocks. This is the least invasive non-breaking change I can make right now. Yes, mocking strategies are basically fucked but I don't want the haste2 integration to have even more breaking changes right now. Consider this code to be temporary, I'll fix this and make the mocking system more sane mid-term.
public
Reviewed By: davidaurelio
Differential Revision: D2889198
fb-gh-sync-id: 58db852ed9acad830538245f7dc347365fe4de38
Summary:
Uses `fastfs.readWhile` to build the haste map
- cuts the time needed to build the haste map in half
- we don’t need to allocate memory for all JS files in the tree
- we only read in as much as necessary during startup
- we only read files completely that are part of the bundle
- we will be able to move the transform before dependency extraction
public
Reviewed By: martinbigio
Differential Revision: D2890933
fb-gh-sync-id: 5fef6b53458e8bc95d0251d0bcf16821581a3362
Summary:
We need to check the existence of RCTLinkingManager (which doesn't exist on Android) because this code is called on require.
Closes https://github.com/facebook/react-native/pull/5680
Reviewed By: svcscm
Differential Revision: D2887260
Pulled By: androidtrunkagent
fb-gh-sync-id: 4a5843ea6a5898d0f2810ad9ddb5b2078054e9f1
Summary:
This error occurs primarily when starting the app and the packager is not running.
`source` can be null when the evaluated code does not come from a source file so it just crashes with a SIGSEGV when passing it to `String::adopt`. This restores the beloved 'Can't find variable __fbBatchedBridge' redbox error :)
Seems to be introduced in 17e1ceb543.
cc davidaurelio
Closes https://github.com/facebook/react-native/pull/5689
Reviewed By: svcscm
Differential Revision: D2890634
Pulled By: astreet
fb-gh-sync-id: b96bbe8e26c9ac580b1aa17222d2f59376832560
Summary:
Original Android's refreshControl in ScrollView is tightly coupled with AndroidSwipeRefreshLayout. If someone use `ref=` for RefreshControl in ScrollView, it does nothing since RefreshControl in Android return null.
This change allows customized RefreshControl especially for `ref=` as well as making ScrollView's code clearer.
Closes https://github.com/facebook/react-native/pull/5623
Reviewed By: svcscm
Differential Revision: D2890072
Pulled By: nicklockwood
fb-gh-sync-id: a8fc7746bcc050a6e46fedf3583979f4cb9021b6
Summary:
DocumentSelectionState returns anchor and focus offsets only in focused state. So TextInput should set proper state to selectionState when blur and focus.
Closes https://github.com/facebook/react-native/pull/5354
Reviewed By: svcscm
Differential Revision: D2890277
Pulled By: andreicoman11
fb-gh-sync-id: 84f96504e218cf7c70d7e24865ab074d882f3bea
Summary:
public
This diff fixes two issues:
1) Makes it so that when a keyboard is displayed, all keys in that keyboard actually can be set as text. Previously you could display a Numeric keyboard and it would only allow entering numbers despite the keyboard having other keys like comma, plus, space, etc.
a) This also allows any key entered on a physical keyboard to go through to the view even if not present on the Soft Input keyboard
2) Makes more robust our Filter setting in setMaxLength so that we only affect the InputFilter.LengthFilter if present instead of all.
This works by creating a new KeyListener which will respond to getInputType as the KeyListener it is replacing (like a DigitsKeyListener for a numeric keyboard) but allow all characters when actually entering text.
Reviewed By: andreicoman11
Differential Revision: D2880851
fb-gh-sync-id: fa5eb549a849d8f30c592d7eac48054ca6a75544
Summary:
The feature added in D2862850 only adds the module that requests shallow dependency resolution to the dependencies of a module. The reason why this is happens is because `collect` calls `response.addDependency` but if `recursive` is set to `false`, dependencies don't call `collect` and therefore don't get added to the resolution response. This fixes it by adding dependencies outside of the `collect` call.
public
Reviewed By: davidaurelio
Differential Revision: D2885152
fb-gh-sync-id: 8ab3b6c6b7cd45d59615a99ac87984a41b5d7025
Summary:
This syncs a couple of changes from GitHub that are necessary for jest:
* Expose `set` on Cache
* Add a function to `getAllModules` from the graph
* Explicitly dontMock `graceful-fs` in the fastfs test. node-haste2 has this manual mock which is still used in automocked tests (ugh!).
public
Reviewed By: davidaurelio
Differential Revision: D2885112
fb-gh-sync-id: b2060d5474ebee5aa13e6ba2bdf5879b46f3fd5f
Summary:
public
https://github.com/facebook/react-native/pull/5494 added a new `source` property to WebView on Android that provides a better API, as well as allowing for request headers to be set.
This diff ports that functionality over to iOS, so we can have a consistent API cross-platform.
I've also extended the API to include `method` (GET or POST) and `body` when setting the WebView content with a URI, and `baseUrl` when setting static HTML.
Reviewed By: javache
Differential Revision: D2884643
fb-gh-sync-id: 83f24494bdbb4e1408aa8f3b7428fee33888ae3a
Summary:
The FS as seen by an instance of a dependency graph is useful for clients of node-haste. This provides an accessor to fastfs so that the partial view of the filesystem can be queried. I was thinking of splitting out the fastfs creation to outside the constructor but the necessary refactoring doesn't seem worth it. The fastfs is intrinsically tied to the dependency graph and the `DependencyGraph` instance is meant to be a base-class for clients anyway. Both in react-packager and jest we are wrapping it with higher-level client specific containers, Resolver and HasteResolver respectively.
public
Reviewed By: davidaurelio
Differential Revision: D2885217
fb-gh-sync-id: 47a408b2682516bee9d6a4e6c61b9063817aaf22
Summary:
Since scrollTo(x,y,**animated**) params has been introduced, it was not backported to ListView scrollTo method.
Closes https://github.com/facebook/react-native/pull/5661
Reviewed By: svcscm
Differential Revision: D2886049
Pulled By: nicklockwood
fb-gh-sync-id: 016e92beadc7f397be77b8c58dc572119f873556
Summary:
This PR modifies the Websocket implementation on iOS to pass cookies to the server. Sending cookies is useful for clients that wish to access protected Websocket endpoints without creating a new authentication protocol.
Closes https://github.com/facebook/react-native/pull/5630
Reviewed By: svcscm
Differential Revision: D2881815
Pulled By: martinbigio
fb-gh-sync-id: 31c1640626cd15447bdb4f2058ae4e34dfa52f88
Summary:
The previous implementation of ColorPropType was very hacky as it used `ReactPropTypes.oneOfType([colorValidator, ReactPropTypes.number])`. It turns out that oneOfType also accepts arbitrary functions instead of a type, but doesn't display any of the error message.
In this diff I properly implement isRequired (sadly we don't export `createChainableTypeChecker` in ReactPropTypes) and provide a lot more context that we have. I copy and pasted the way we displayed this context from the existing checkers.
**Test Plan**
When doing .isRequired and do not provide the value:
When providing a bad value:
Closes https://github.com/facebook/react-native/pull/5671
Reviewed By: svcscm
Differential Revision: D2886760
Pulled By: vjeux
fb-gh-sync-id: d6be42b5768fca5463fe80fe4b144506d21b0832
Summary:
public
Introduce a header bar similar to the one shown when loading the bundle to indicate that the packager server is processing an HMR update. Hook into HMR events to show this bar when appropriate.
Reviewed By: javache
Differential Revision: D2873521
fb-gh-sync-id: a77cbb2368b75b045aa8c6ababce2f731baf514b
Summary:
public
My refactor to unify the scrollTo() apis on iOS + Android broke iOS. Oops.
Reviewed By: jingc
Differential Revision: D2886305
fb-gh-sync-id: de287cba8df7cf14c8049d91621cd7f86aa4e92c
Martin Kralik
Janic Duplessis
Dave Miller
Nick Lockwood
Krzysztof Magiera
joranz
Christoph Pojer
David Aurelio
Chirag
Thomas Goldenberg
AnishKumar Dubey
Richard Lai
Adam Miskiewicz
Kudo Chien
Konstantin Raev
Aleksei Androsov
Andrei-Ovidiu Coman
Jan Kassens
glevi@fb.com
Gaëtan Renaudeau
Jelle van den Hooff
Ilana Sufrin
Christopher Chedeau
Martín Bigio
Brent Vatne
