Summary:
public
Expose JS hooks to create flow events in systrace (the nice arrows to show async work flow) +
add support to the showing all the work enqueued from the JS thread as added in D2743733
Depends on D2743733
Reviewed By: jspahrsummers
Differential Revision: D2815293
fb-gh-sync-id: 4278f61a67a6e78cf2704bacce34b1389328c6df
Summary:
RefreshControl did not start refreshing when refreshing was set to true initially. It also did not start refreshing on iOS when setting the prop from false to true without doing a pull to refresh gesture.
This was a pain in the ass to make work on iOS because UIRefreshControl seems super sensitive to when beginRefreshing can be called, for the initial render I need to call it in layoutSubviews. I also have to manually adjust the scrollview content offset when calling beginRefreshing. The code is a bit hacky but it was the only solution I found that was actually working.
Fixes#5716
Closes https://github.com/facebook/react-native/pull/5745
Reviewed By: svcscm
Differential Revision: D2910716
Pulled By: nicklockwood
fb-gh-sync-id: d60e73bcfe8d86bb01249ba5f17e6a23c5a5aff6
Summary:
We should have 0 logs at startup. In theory it could be useful to know if the profiler is enabled, but in practice 99% of the time you don't care and it ends up spamming you for no good reason. Then more people add logs and not only do the logs are not useful, they prevent people from actually using them when debugging.
Closes https://github.com/facebook/react-native/pull/5766
Reviewed By: svcscm
Differential Revision: D2902987
Pulled By: androidtrunkagent
fb-gh-sync-id: d47f8e58edf5f2c8e2a7a4373fd7d9036d2309a0
Summary:
When scrolling while RefreshControl is refreshing the sticky headers are offset by the height of the UIRefreshControl. This simply removes the height of the UIRefreshControl while it is refreshing and fixes the problem.
You can repro the bug using this example in UIExplorer by doing a pull to refresh and scrolling the ListView immediately after.
https://gist.github.com/janicduplessis/26b4f2758e90b2aa1620Fixes#5405
Closes https://github.com/facebook/react-native/pull/5517
Reviewed By: svcscm
Differential Revision: D2895623
Pulled By: nicklockwood
fb-gh-sync-id: 81df36cccfc3e7b973c2be78565f8b8408c9fc12
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:
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
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:
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
Summary:
We were executing all the updateBlocks for every frame that was updated in the UI flush. This would quickly give you an explosive number of block calls when loading complex views.
This update block is only really used by text to propagate padding, even though the actual insets are mostly just 0.
public
Reviewed By: nicklockwood
Differential Revision: D2848968
fb-gh-sync-id: e43c529c2bb9729e2b779bf4abefeed58775cc2e
Summary:
For my project it was required to receive a notification when the MapView annotation was deselected.
So I renamed `onAnnotationPress` to `onAnnotationSelected` and added a new method `onAnnotationDeselected`, this names was "inspired" by the underlaying iOS API. The old API was still called and marked as deprecated.
But maybe you have an idea for a better naming (onAnnotationFocus/-Blur?) -- or should a deselected call the press method again without an annotation (undefined)?
Closes https://github.com/facebook/react-native/pull/5167
Reviewed By: svcscm
Differential Revision: D2869695
Pulled By: nicklockwood
fb-gh-sync-id: 91795ac3f1e4533b250af8901534d8870729d9db
Summary:
Expose a `decelerationNormalEnabled` flag on WebView, which, when enabled, will WebView's ScrollView's `decelerationRate` to `UIScrollViewDecelerationRateNormal`. This gives the WebView the same "momentum" style scrolling as other iOS views.
This was discussed with ide in #5447. Please let me know if there's anything I'm missing, or anything else you'd like to see in this pull request.
Closes https://github.com/facebook/react-native/pull/5527
Reviewed By: svcscm
Differential Revision: D2870312
Pulled By: nicklockwood
fb-gh-sync-id: 7dbfd06a349e3365a5df40c3bacf25a4fdb306cf
Summary:
An initial implementation was done on css-layout but isn't working correctly on many cases. The binding from React Native has been removed a long time ago. Let's not confuse people and remove it from the docs :)
Closes https://github.com/facebook/react-native/pull/5522
Reviewed By: svcscm
Differential Revision: D2859665
Pulled By: vjeux
fb-gh-sync-id: 4aa008dd93a6cea6b79a7bce444c94148791eee4
Summary:
public
To make sourcemaps work on Hot Loading work, we'll need to be able to serve them for each module that is dynamically replaced. To do so we introduced a new parameter to the bundler, namely `entryModuleOnly` to decide whether or not to process the full dependency tree or just the module associated to the entry file. Also we need to add `//sourceMappingURL` to the HMR updates so that in case of an error the runtime retrieves the sourcemaps for the file on which an error occurred from the server.
Finally, we need to refactor a bit how we load the HMR updates into JSC. Unfortunately, if the code is eval'ed when an error is thrown, the line and column number are missing. This is a bug/missing feature in JSC. To walkaround the issue we need to eval the code on native. This adds a bit of complexity to HMR as for both platforms we'll have to have a thin module to inject code but I don't see any other alternative. when debugging this is not needed as Chrome supports sourceMappingURLs on eval'ed code
Reviewed By: javache
Differential Revision: D2841788
fb-gh-sync-id: ad9370d26894527a151cea722463e694c670227e
Summary:
public
This diff improves the implementation of 3D touch by adding a `forceTouchAvailable` constant to View that can be used to check if the feature is supported.
I've also added an example of how you can use the `force` property of the touch event to measure touch pressure in React Native.
Reviewed By: vjeux
Differential Revision: D2864926
fb-gh-sync-id: 754c54989212ce4e4863716ceaba59673f0bb29d
Summary:
This adds the first of the three 3dTouch API types, that found on the touch event.
It adds the `force` prop to touch events when running on iOS 9 devices:
Closes https://github.com/facebook/react-native/pull/3055
Reviewed By: svcscm
Differential Revision: D2860540
Pulled By: nicklockwood
fb-gh-sync-id: 95a3eb433837c844f755b3ed4a3dfcb28452c284
Summary:
public
NSJSONSerialization throws an exception when it encounters bad JSON data, including NaN values, which may not be a programming error.
This diff adds code to catch those exceptions and convert to an error. Also, if no error handling is in place, RCTJSONStringify will now display a redbox, and attempt to recover by sanitizing the JSON data and retrying.
Reviewed By: javache
Differential Revision: D2854778
fb-gh-sync-id: 18e6990af0d91083496d6a0b75c31a94ed9454a5
Summary:
I am using ReactNative in a hybrid App.
We have a setup like so:
Native Navigation Controller
Native Tab Controller
Native View Controller wrapping React
React Navigation Controller
React View Controller 1
React View Controller 2
Native View Controller 2.
When I pop Native View Controller 2 off the Navigation stack, I get a seg fault on this line:
NSUInteger indexOfFrom = [_currentViews indexOfObject:fromController.navItem];
I believe what's happening:
Your code is listening to Nav Controller transitions, assuming that they are all from React Native Nav Controllers.
You are catching this one instead, which is actually a Native Nav Controller transition.
You start trying to access the pushed/popped view controllers as if they were react native view controllers.
In this case, the view controllers are not react native -> no navItem field -> seg fault.
Solution: if we are catching this transition but it isn't from our react native nav controller, just
Closes https://github.com/facebook/react-native/pull/5495
Reviewed By: svcscm
Differential Revision: D2857473
Pulled By: nicklockwood
fb-gh-sync-id: cc7f0a16e2e0cea56ca9e49bcb87db4ebd3a0905
Summary:
public
This diff fixes a bug in RCTScreenScale() on iPhone6+. The issue was due to the fact that the iPhone6+'s virtual screen resolution of 414x736 points 3x resolution (1242x2208 pixels) does not match its actual screen resolution, which is 1080p (1080x1920 pixels).
I did not realize that `[UIScreen mainScreen].nativeBounds` reports the *actual* resolution, not the virtual resolution, and was dividing by the virtual scale (3.0) instead of the actual native scale factor (2.6).
This only affects iPhone6+, because for all other iOS devices, the virtual resolution matches the native resolution.
Reviewed By: milend
Differential Revision: D2854663
fb-gh-sync-id: bce8965a151e2f005a02a5f6b54f259d01b9ab12
Summary:
public
Although the feature itself is gated, once the user is on the experiment we want to make sure hot loading starts disabled up until the feature is enabled through the dev menu.
Reviewed By: javache
Differential Revision: D2850070
fb-gh-sync-id: 66e69e152806d3bb01985afe20827e3b9cffeb41
Summary:
Ok, so this started as fixing #5273 but ended up getting a little more complicated. 😄
Currently, AlertIOS has the following API:
* `alert(title, message, buttons, type)`
* `prompt(title, defaultValue, buttons, callback)`
I've changed the API to look like the following:
* `alert(title, message, callbackOrButtons)`
* `prompt(title, message, callbackOrButtons, type, defaultValue)`
I know that breaking changes are a big deal, but I find the current alert API to be fairly inconsistent and unnecessarily confusing. I'll try to justify my changes one by one:
1. Currently `type` is an optional parameter of `alert`. However, the only reason to change the alert type from the default is in order to create one of the input dialogs (text, password or username/password). So we're in a weird state where if you want a normal text input, you use `prompt`, but if you want a password input you use `alert` with the 'secure-text' type. I've moved `type` to `prompt` so all text input is now done with `pro
Closes https://github.com/facebook/react-native/pull/5286
Reviewed By: svcscm
Differential Revision: D2850400
Pulled By: androidtrunkagent
fb-gh-sync-id: 2986cfa2266225df7e4dcd703fce1e322c12b816
Summary:
public
Standardises the image decoding logic for all image sources, meaning we get the benefits of efficient downscaling of images from all sources, not just ALAssets.
Reviewed By: javache
Differential Revision: D2647083
fb-gh-sync-id: e41456f838e4c6ab709b1c1523f651a86ff6e623
Summary:
This solves https://github.com/facebook/react-native/issues/5090. Since 5b4e873c68 we had better reporting for when calls from native to JS fail. When trying to load an invalid bundle, this would now cause a stackoverflow, since RCTFatal would schedule a JS call to log, which would RCTFatal, which would ...
By invalidating the jsExecutor immediately after loading fails, we prevent any more attempts to log. We can't invalidate the whole bridge at this point since we still need the redbox module to actually display the error.
public
Reviewed By: majak
Differential Revision: D2834251
fb-gh-sync-id: a3e2ad425e40560beae4d3eacb93f66ace5341bf
Summary:
public
Promises are coming. And as part of it, we are standardizing the error objects that will be returned. This puts the code in place on the Android side to always send the proper error format.
It will be an error object like this
{
code : "E_SOME_ERROR_CODE_DEFINED_BY_MODULE", // Meant to be machine parseable
message : "Human readable message",
nativeError : {} // Some representation of the underlying error (Exception or NSError) , still figuring out exactly, but hopefully something with stack info
}
Reviewed By: nicklockwood
Differential Revision: D2840128
fb-gh-sync-id: 174d620e2beb53e1fc14161a10fd0479218d98a6
Summary:
This caused issues for me when I tried to provide a native module on init that was also KVO'd (and dynamically subclassed)
On closer inspection, it also seems highly inconsistent to register these classes in DEBUG mode but have them fail silently in production. Reducing the difference between debug and release seems like a safer option.
public
Reviewed By: nicklockwood
Differential Revision: D2819838
fb-gh-sync-id: 79ab72b1152c89eae38c965ff7724aba59a00949
Summary:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
public
React Native currently exposes the iOS layer shadow properties more-or-less directly, however there are a number of problems with this:
1) Performance when using these properties is poor by default. That's because iOS calculates the shadow by getting the exact pixel mask of the view, including any tranlucent content, and all of its subviews, which is very CPU and GPU-intensive.
2) The iOS shadow properties do not match the syntax or semantics of the CSS box-shadow standard, and are unlikely to be possible to implement on Android.
3) We don't expose the `layer.shadowPath` property, which is crucial to getting good performance out of layer shadows.
This diff solves problem number 1) by implementing a default `shadowPath` that matches the view border for views with an opaque background. This improves the performance of shadows by optimizing for the common usage case. I've also reinstated background color propagation for views which have shadow props - this should help ensure that this best-case scenario occurs more often.
For views with an explicit transparent background, the shadow will continue to work as it did before ( `shadowPath` will be left unset, and the shadow will be derived exactly from the pixels of the view and its subviews). This is the worst-case path for performance, however, so you should avoid it unless absolutely necessary. **Support for this may be disabled by default in future, or dropped altogether.**
For translucent images, it is suggested that you bake the shadow into the image itself, or use another mechanism to pre-generate the shadow. For text shadows, you should use the textShadow properties, which work cross-platform and have much better performance.
Problem number 2) will be solved in a future diff, possibly by renaming the iOS shadowXXX properties to boxShadowXXX, and changing the syntax and semantics to match the CSS standards.
Problem number 3) is now mostly moot, since we generate the shadowPath automatically. In future, we may provide an iOS-specific prop to set the path explicitly if there's a demand for more precise control of the shadow.
Reviewed By: weicool
Differential Revision: D2827581
fb-gh-sync-id: 853aa018e1d61d5f88304c6fc1b78f9d7e739804
Summary:
public
This diff deprecates `scrollResponderScrollWithoutAnimationTo` and replaces it with an optional `animated` param in `scrollResponderScrollTo`. This is more consistent with our other APIs.
Using the old `ScrollResponder.scrollResponderScrollWithoutAnimationTo` or `ScrollView.scrollWithoutAnimationTo` functions will still work, but will trigger a warning.
Reviewed By: javache
Differential Revision: D2823479
fb-gh-sync-id: 259966512104ca7b3995c9586144812a91b8d3e9
Summary:
public
The fix for border smearing introduced a bug where borders + background would sometimes not be rendered if the view was created at a small size (e.g. zero) and then resized.
This diff fixes that by redrawing the border if the view size changes. There is some opportunity to optimize this in future by performing some logic up-front to detect if the redrawing is necessary, but I thought I'd keep it simple for this bug fix rather than risk introducing further bugs.
Reviewed By: jingc
Differential Revision: D2817365
fb-gh-sync-id: eca164e8ce03a66598677c9e05496791230b5210
Tadeu Zagallo
Janic Duplessis
Christopher Chedeau
Ian Cervantez
Pieter De Baets
Martin Kralik
Nick Lockwood
Martín Bigio
Christoph Jerolimov
August Flanagan
Jean Regisser
Matt Apperson
tuyou
Satyajit Sahoo
DougBanksPersonal
Kyle Corbitt
tantan
Dave Miller
Gaëtan Renaudeau