Summary: The new CSSLayout have a wrong calculate for the getRelativePosition. So use the getLeadingPosition will get 0 instead of return undefined. Fix it with using isLeadingPosDefined.
Reviewed By: fkgozali
Differential Revision: D3640799
fbshipit-source-id: 50d3bd2ea4c0d8bf96ba34297425ba269b0535cd
Summary:
The make current RCTShadowView support RTL layout.
Two changes I made:
1 Change all left/right to start/end for margin, padding, boarder and position
2 Change the paddingAsInsets to support RTL
Reviewed By: majak
Differential Revision: D3548002
fbshipit-source-id: 15cc5228d2d28d0e12a7147daf57967e5b87ee63
Summary:
The current CSSLayout can't support RTL because wrong calculation for absolute position.
This change is mainly to fix the issue: https://github.com/facebook/css-layout/issues/197
Three main problems I fixed:
1. Calculate the position in the same way as margin, boarder, and padding. So that to fix the absolute problem.
2. Fix one wrong calculation for leading value when we only know the trailing value. It was hard code for the LTR situation. Now I changed it to depends on the main Axis.
3. Expose getter and setter function for RN to read layout direction and start/end position value.
Reviewed By: fkgozali
Differential Revision: D3616949
fbshipit-source-id: ae7a47cc0a5d02b42b95f87232be51ab144056d9
Summary: Mirrors Android's support for multiple sources for Image, allowing us to fetch new images as the size of the view changes.
Reviewed By: mmmulani
Differential Revision: D3615134
fbshipit-source-id: 3d0bf2b75f63a4379e0e49f2dab9aea351b31d5f
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary: RCTShadowText currently overrides a couple methods from RCTShadowView to reset the count of the cssNode children to 0. This diff instead moves that logic into RCTShadowView behind a configurable flag making it easier to reason about.
Reviewed By: javache
Differential Revision: D3586434
fbshipit-source-id: 4389a8119dc49e3fc4357174c87c0c69287ae385
Summary: fillCSSNode was only ever used in RCTShadowView to set the child count which is already performed in insert/remove subview calls and in RCTShadowText is was used to set the measure function which can be done in the initializer instead.
Reviewed By: majak, javache
Differential Revision: D3586418
fbshipit-source-id: de2155daf0f1702c8977bf23183a3b6a650d016b
Summary: Add some additional perf markers, and remove the usage of RCTProfileBlock as it completely breaks debugging / stepping in those blocks.
Reviewed By: majak
Differential Revision: D3579900
fbshipit-source-id: 8846dfc39b2448daa3669d5e1e8efb9096f183c5
Summary:
As per javache comments in #8734.
Also removes now useless feature detection check.
**Test plan**
Tested that rIC still works in UIExplorer example.
Closes https://github.com/facebook/react-native/pull/8795
Differential Revision: D3572566
Pulled By: javache
fbshipit-source-id: 261d13d8b03898313f8b4184d634c70f81a61b62
Summary: Instead of the somewhat odd concept of a "packager running predicate", just expose a class method for generating a JS bundle URL given a host, root, and options. This can be used by consumers that need custom behavior.
Reviewed By: javache
Differential Revision: D3564185
fbshipit-source-id: b1a7e66a2dada6a9eefe783b12b03fca7a330be3
Summary:
iOS follow up to #8569. This currently depends on the Android PR since it contains the JS implementation, only review the last commit. Just putting this out here for visibility, don't merge this before the Android PR.
**Test plan**
Tested by running a background task that burns all remaining idle time (see UIExplorer example).
Tested that native only calls into JS when there are pending idle callbacks.
Tested that timers are executed before idle callback.
Closes https://github.com/facebook/react-native/pull/8734
Differential Revision: D3560818
fbshipit-source-id: a28d3092377a7fd4331647148d40fe69e4198c7e
Summary: The docs for this new method explain what it does.
Differential Revision: D3556890
fbshipit-source-id: b075e750cdd1e7354e0a26c03b3fd74cca52aeb7
Summary:
- Avoid using `+initialize`, use dispatch_once instead; it should be equivalent but more performant.
- Don't even let the `isPackagerRunning:` and `guessPackagerHost` methods exist unless `RCT_DEV` is on; they didn't do anything interesting when it is off.
Reviewed By: javache
Differential Revision: D3556645
fbshipit-source-id: 7dcdb4ae27f6625010e15846d757269f6f04155c
Summary: Include the actual scheme instead of "non-file".
Reviewed By: javache
Differential Revision: D3555812
fbshipit-source-id: 3ae0490f2d8fae01a551ba2877789dc15818fc50
Summary:
WebView component detect phone numbers in html as URL links by default. But sometimes we don't want this behavior.
This PR add dataDetectorTypes as a prop of WebView, so one can specify value of this prop as one or more of phoneNumber/link/address/calendarEvent/none/all
This prop maps to UIWebView.dataDetectorTypes
Closes https://github.com/facebook/react-native/pull/8743
Differential Revision: D3556440
fbshipit-source-id: 55f01d2cdd785381f261a9dc931aa9311f0ad1d4
Summary: No need to specify duplicative information.
Reviewed By: javache
Differential Revision: D3550805
fbshipit-source-id: b5abc3f1c74e26b4d4641c29fedba189cc46406e
Summary:
Attempt to fix#7919.
Currently, if the app is launched into the background and you read `AppState.currentState` too soon, you will see the value `'active'` instead of `'background'`. This is because the default value of `AppState.currentState` is hardcoded to be `'active'` and it is initialized with the actual value asynchronously.
This attempts to fix the bug by having the `RCTAppState` module provide the initial state as a module constant.
As noted in #7919, it looks like this fix was already tried and reverted with 0fb3d8de83. zjj010104, hedgerwang, nicklockwood -- can you explain why? I would very much like to get this bug fixed. Nobody has followed up on the issue I filed so I decided to just go ahead and make a PR with my best guess at a fix.
**Test plan (required)**
Built a small app as described in the repro steps for #7919 and verified that, when the app is launched into the background, `init currentState: background` is printed. Also verified that `i
Closes https://github.com/facebook/react-native/pull/8058
Differential Revision: D3554619
fbshipit-source-id: 5d950b85e335765552bbd3cf6ed91534062e35a1
Summary: This prevents the `isUnbundle` check to read beyond the end of an `NSData` instance by using `getBytes:length:` instead of accessing the underlying buffer directly.
Reviewed By: javache
Differential Revision: D3548874
fbshipit-source-id: 7c93c66cc6abb4a2a321888ab394212f4d14a03e
Summary: The loader should be a utility that stands alone. The bridge uses the loader, not the other way around.
Reviewed By: bnham
Differential Revision: D3546157
fbshipit-source-id: 91016afb629df1f8c83c8fca6f42649be0b046b0
Summary:
This diff exposes a new experimental method `[RCTJavaScriptLoader +attemptSynchronousLoadOfBundleAtURL:sourceLength:error:]`. It may be used if you know that a specific call site must load its JavaScript synchronously, or else fail entirely.
This new API will succeed for file URLs that point to a RAM bundle. It will fail for non-RAM-bundle files and for HTTP URLs.
This also cleans up the error domain and codes for this class. This should be the only externally visible change from this diff if you don't use the new API: the codes and domains you receive from the API may change slightly. They were pretty sloppy and undocumented before, so I think this change is for the better.
Reviewed By: bnham
Differential Revision: D3545956
fbshipit-source-id: 30e65f4e8330d2d68f3f50ade077fdc1db4a435e
Summary:
The `initWithJSContextProvider:` API created a `RCTJSCExecutor` with a thread/context that already exists, but it did not solve the problem of loading an actual application script; the `executeApplicationScript:` API is also asynchronous.
Create a new merged API that allows you to pass in a pre-created thread/context pair and immediately receive an `RCTJSCExector` that has already executed a specified application script.
This also removes the `underlyingJSContext` API entirely, in favor of passing it back in a byref variable in the new API. This minimizes the surface area for API abuse.
Reviewed By: bnham
Differential Revision: D3545349
fbshipit-source-id: 1c564f44d2a5379b5e6f75640079a28fd7169f67
Summary:
Instead of two separate dispatches to the JavaScript thread, only do one. Avoid the strongSelf dance entirely.
This refactor does mean that the cost of registering the nativeRequire hook on the context is not measured by the `RCTPLRAMBundleLoad` tag. However it should be almost zero-cost to construct and set a single block, so I'm OK with that change.
Reviewed By: bnham
Differential Revision: D3542940
fbshipit-source-id: d6bd26e478d0d33b56f8116d7efe6aac80c91711
Summary: We deprecated it a while back and nobody is using it internally.
Reviewed By: majak
Differential Revision: D3542602
fbshipit-source-id: dfe11a47b21d2f8a7c946c902f0ea427615ffc31