Summary: Fixed broken scaling logic in Webview example for iOS. Pages must be reloaded after toggling `scalesPageToFit`, but that wasn't happening.
Reviewed By: javache
Differential Revision: D2982371
fb-gh-sync-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
shipit-source-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
Summary:The `uiBlockToAmendWithShadowViewRegistry:` is called on every single view manager, on every single layout pass. This causes all view managers to be eagerly intiialized, even if not being used.
In practice very few modules actually use this method, so by checking if the method is implemented before calling it, we can eliminate most of this work.
(Hopefully in future we can get ride of this method altogether, but right now it's integral to the way that text layout is implemented).
Reviewed By: majak, javache
Differential Revision: D2982181
fb-gh-sync-id: 818d0aac61197df89263c919c2c80a003e293ac5
shipit-source-id: 818d0aac61197df89263c919c2c80a003e293ac5
Summary:The RCTPerformanceLogger log the time in ms not us. Especially the unit of RCTPLBundleSize is byte.
Closes https://github.com/facebook/react-native/pull/5919
Differential Revision: D2982116
Pulled By: nicklockwood
fb-gh-sync-id: 18aad5ff2eb83c6f302b2c10382bf214b51df133
shipit-source-id: 18aad5ff2eb83c6f302b2c10382bf214b51df133
Summary: When rotating on iPad, the dev loading view just looks clowny since it doesn't rotate properly.
Reviewed By: majak
Differential Revision: D2939721
fb-gh-sync-id: 7f1926f5cee4761cde8881e9387ae6e0063c5d6c
shipit-source-id: 7f1926f5cee4761cde8881e9387ae6e0063c5d6c
Summary:Unfortunately the 'screen' option in the `UIManager.takeSnapshot` API appears to work only on the iOS simulator, not on an actual device.
This diff removes the 'screen' option until a solution can be found that works on the device.
(Taking a snapshot of the window still works fine - it just won't include the status bar, etc.)
Reviewed By: javache
Differential Revision: D2971091
fb-gh-sync-id: 026b9d4eb2f59f686f58c18a16381ff325df612b
shipit-source-id: 026b9d4eb2f59f686f58c18a16381ff325df612b
Summary:This adds a `takeSnapshot` method to UIManager that can be used to capture screenshots as an image.
The takeSnapshot method accepts either 'screen', 'window' or a view ref as an argument.
You can also specify the size, format and quality of the captured image.
I've added an example of capturing a screenshot at UIExplorer > Snapshot / Screenshot.
I've also added an example of sharing a screenshot to the UIExplorer > ActionSheetIOS demo.
Reviewed By: javache
Differential Revision: D2958351
fb-gh-sync-id: d2eb93fea3297ec5aaa312854dd6add724a7f4f8
shipit-source-id: d2eb93fea3297ec5aaa312854dd6add724a7f4f8
Summary: When rotating a modal view we should adjust the root view's frame.
Reviewed By: majak
Differential Revision: D2939712
fb-gh-sync-id: 974634276d2c0ad22b46976020d0a21e1dac9026
shipit-source-id: 974634276d2c0ad22b46976020d0a21e1dac9026
Summary:The bug is caused by a weird race condition. What happens is that when calling `UIRefreshControl#endRefreshing` the `UIScrollView` delegate `scrollViewDidScroll` function is called synchronously and then `dockClosestSectionHeader` crashes because the sticky header indexes are updated but not the contentView children.
I fixed it by adding an updating property on `RCTRefreshControl` and setting it before calling `endRefreshing` so we can know not to call `dockClosestSectionHeader` at that moment.
Tested with both `RefreshControl` and `onRefreshStart` prop.
I reproduced the bug by replacing ListViewExample.js in UIExplorer with https://gist.github.com/janicduplessis/05fc58e852f3e80e51b9Fixes#5440
cc nicklockwood
Closes https://github.com/facebook/react-native/pull/5445
Differential Revision: D2953984
Pulled By: nicklockwood
fb-gh-sync-id: c17a6a75ab31ef54d478706ed17a8115a11d734e
shipit-source-id: c17a6a75ab31ef54d478706ed17a8115a11d734e
Summary:New prop `hitSlop` allows extending the touch area of Touchable components. This makes it easier to touch small buttons without needing to change your styles.
It takes `top`, `bottom`, `left`, and `right` same as the `pressRetentionOffset` prop. When a touch is moved, `hitSlop` is combined with `pressRetentionOffset` to determine how far the touch can move off the button before deactivating the button.
On Android I had to add a new file `ids.xml` to generate a unique ID to use for the tag where I store the `hitSlop` state. The iOS side is more straightforward.
terribleben worked on the iOS and JS parts of this diff.
Fixes#110
Closes https://github.com/facebook/react-native/pull/5720
Differential Revision: D2941671
Pulled By: androidtrunkagent
fb-gh-sync-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194
shipit-source-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194
Summary:
public
In 9baff8f437 (diff-8d9841e5b53fd6c9cf3a7f431827e319R331), I incorrectly assumed that iOS was wrapping promises in an extra Array. What was really happening is that all the callers were doing this. I removed the wrapping in the callers and the special case handling MessageQueue.
Now one can pass whatever object one wants to resolve and it will show properly in the resolve call on the js side. This fixes issue https://github.com/facebook/react-native/issues/5851
Reviewed By: nicklockwood
Differential Revision: D2921565
fb-gh-sync-id: 9f81e2a87f6a48e9197413b843e452db345a7ff9
shipit-source-id: 9f81e2a87f6a48e9197413b843e452db345a7ff9
Summary:
This commit adds the delegate hooks so that local notifications get
passed onto the JS and adds a new event listener type for local
notifications.
Also add functions to clear local notifications
Closes https://github.com/facebook/react-native/pull/2084
Reviewed By: svcscm
Differential Revision: D2908096
Pulled By: nicklockwood
fb-gh-sync-id: 759d299ea35abea177e72934076297d666d3ea20
shipit-source-id: 759d299ea35abea177e72934076297d666d3ea20
Summary:
public
Lazy export of module constants required a sync dispatch to the main thread, which was deadlocking in some of our projects.
This moves the constants export to the initial bridge init, which may slightly increase initial startup time, but avoids the deadlock.
Reviewed By: javache
Differential Revision: D2911295
fb-gh-sync-id: 0d14a629ac4fc7ee21acd293c09595c18232659b
shipit-source-id: 0d14a629ac4fc7ee21acd293c09595c18232659b
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
Summary:
public
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just `<Image/>` and `<Text/>` components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except `<Text/>` nodes. It might still be useful for `<Image/>` nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
Note that this diff does not prevent you from eliminating blending on image components by manually setting an opaque background color, nor does it stop you from disabling color propagation on text components by manually setting a transparent background.
Reviewed By: javache
Differential Revision: D2811031
fb-gh-sync-id: 2eb08918c9031c582a3dd2d40e04b27a663dac82
Summary:
public
The props argument of the `-[RCTComponentData createView:props:]` method was removed,
but the C function used to swizzle it in the profiler wasn't updated.
Reviewed By: majak
Differential Revision: D2811228
fb-gh-sync-id: 8896638c77370142e29913b5fb80e7fd748254b5
Summary:
public
Since we don't actually recreate our native modules every time (will fix in follow-up), we'd never update the reference after reloading the bridge, and all navigation would fail.
Reviewed By: majak
Differential Revision: D2811406
fb-gh-sync-id: 4f4fd73bbdecfe510e1e1554668b2354181f22a8
Summary:
public
The iOS border rendering code did not follow the CSS spec in cases where the sum of adjacent border radii was greater than the width of the view, resulting in drawing glitches such as pixel smear and borders appearing stretched or squashed.
This diff brings our implementation closer to spec-compliance in these cases. I also fixed a longstanding issue with ghostly diagonal lines appearing at the corners due to antialiasing rounding errors!
Fixes
https://github.com/facebook/react-native/issues/1572https://github.com/facebook/react-native/issues/2089https://github.com/facebook/react-native/issues/4604
Reviewed By: tadeuzagallo
Differential Revision: D2811249
fb-gh-sync-id: c3dd2721e0a01a432fa4dc78daa05680595edd08
Summary:
public
Attempting to load an undefined URL via XMLHttpRequest produced a confusing error deep within the network layer. This diff improves the networking stack to catch such errors earlier, and also adds a helpful error in the JS layer.
Fixes https://github.com/facebook/react-native/issues/4558
Reviewed By: javache
Differential Revision: D2811080
fb-gh-sync-id: 1837427e1080a0308f2c4f9a8a42bce2e041fb48
Summary:
public
Fixed a potential deadlock issue if code attempted to access a module via [bridge moduleForName/Class:] while it was being initialized.
Reviewed By: lry
Differential Revision: D2807827
fb-gh-sync-id: 58cafe9b92c094dde632d17245fb9b342a0fe9e0
Summary:
public
By doing this we fix 2 problems:
1. We use the same url, both the first time the simulator starts with Hot Loading disabled (no `hot` attribute), and after HL has been enabled and then disabled ('hot=false'). By doing so, the packager will rebuild more than one bundle as file changes. We could have ignored this attribute on the packager but I'd rather not contaminate the server with it and instead make the clients send only 2 types of URLs.
2. The code on `RCTBatchedBridge.m` that decides whether or not to enable HMR does so by looking at presence of the query string parameter `hot`. If the parameter is present, even when it's false, it will try to enable HL, which is wrong.
Reviewed By: nicklockwood
Differential Revision: D2807512
fb-gh-sync-id: 728b680c2383c328d8967d34c10e7a6288e455ac
Summary:
public
Android implement ViewManager methods via a dispatch method on UIManager, whereas iOS implements them by exposing the methods on the view manager modules directly.
This diff polyfills Android's implementation on top of the iOS implementation, allowing the same JS API to be used for both.
Reviewed By: javache
Differential Revision: D2803020
fb-gh-sync-id: 0da0544e593dc936467d16ce957a77f7ca41355b
Summary:
public
Unfortunately, it turns out that NSURLComponents.queryItems only works on iOS 8 and above. This diff re-implements the RCTGetURLQueryParam and RCTURLByReplacingQueryParam functions using functionality available in iOS 7.
Reviewed By: javache
Differential Revision: D2803679
fb-gh-sync-id: 56f10bef4894d16197975b6023b7aa5ab106d8cb
Summary:
public
The logic inside RCTBatchedBridge contained some race conditions that would occasionally cause an error if modules were loaded in the wrong order. This improves that logic and makes it safer by adding a lock to prevent concurrency.
Reviewed By: jspahrsummers
Differential Revision: D2802930
fb-gh-sync-id: d1ad25fa578649363dcaac029cb24dc3a453ae67
Summary:
public
This exposes a proper API for adding synchronous callbacks to JS, as an optional feature of the executor.
This is based on nicklockwood's work in D2764492, but avoids refactoring bridge/executor interactions for the time being, since we agree on this API and can move the actual callsites around later.
Reviewed By: nicklockwood
Differential Revision: D2799506
fb-gh-sync-id: af209d9a0be927f3404205feb16e59745cc37aec
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: D2773664
fb-gh-sync-id: 4a8854b17b4741b882f5f2cc425e4237a5e4b3eb
Summary:
Both iOS and Android currently support some sort of native pull to refresh control but the API was very different. I tried implementing a component based on PullToRefreshViewAndroid but that works on both platforms.
I liked the idea of wrapping the ListView or ScrollView with the PullToRefreshView component and allow styling the refresh view with platform specific props if needed. I also like the fact that 'refreshing' is a controlled prop so there is no need to keep a ref to the component or to the stopRefreshing function.
It is a pretty rough start so I'm looking for feedback and ideas to improve on the API before cleaning up everything.
On iOS we could probably deprecate the onRefreshStart property of the ScrollView and implement the native stuff in a PullToRefreshViewManager. We could then add props to customize the look of the UIRefreshControl (tintColor). We could also deprecate the Android only component and remove it later.
Closes https://github.com/facebook/react-native/pull/4915
Reviewed By: svcscm
Differential Revision: D2799246
Pulled By: nicklockwood
fb-gh-sync-id: 75872c12143ddbc05cc91900ab4612e477ca5765
Summary:
public
The implementation of the `methodQueue` lazy initializer in `RCTModuleData` could result in the queue being set twice, because calling `methodQueue` for a module that hasn't been instantiated would call `RCTModuleData.instance` to create the module, which itself calls `methodQueue`.
It's not clear if this was causing a bug, but it may be related to an occasional bug where the `RCTViewManager.methodQueue` returns nil.
Reviewed By: majak
Differential Revision: D2783320
fb-gh-sync-id: 9194da0fd7392f63825da1f5c450363dd300b635
Walter Luh
Martín Bigio
Nick Lockwood
wenzhao.yin
Pieter De Baets
Janic Duplessis
Jesse Ruder
Scott Kyle
Adam Miskiewicz
Dave Miller
slycoder
Tadeu Zagallo
Christopher Chedeau
Ian Cervantez
Martin Kralik
Christoph Jerolimov
August Flanagan
Jean Regisser
Matt Apperson
tuyou
Satyajit Sahoo
DougBanksPersonal
Kyle Corbitt
tantan
Gaëtan Renaudeau
Quentin Valmori
Justin Spahr-Summers
Fada Chen
Jason Brown
Jed Lau
Mike Armstrong
