Summary:This adds support for delete view animations in LayoutAnimation for iOS. It supports the same properties as the create animation (alpha, scale).
This allows making simple animations when removing a view which is normally hard to do in React since we need to not remove the view node immediately.
**Test plan**
Tested add/removing views in the UIExample explorer with and without setting a LayoutAnimation. Also tested that the completion callback still works properly. Tested that user interation during the animation is properly disabled.
I also plan to work on improving the doc for LayoutAnimation as well as making this PR for android too.
Closes https://github.com/facebook/react-native/pull/6779
Differential Revision: D3215525
Pulled By: sahrens
fb-gh-sync-id: 526120acd371c8d1af433e8f199cfed336183775
fbshipit-source-id: 526120acd371c8d1af433e8f199cfed336183775
Summary:Hey,
I have been going through some UIAlert related issues in the repo trying to fix them, and one of the steps to start reproducing them was to put `Alert.alert()` call right inside `componentDidMount`.
However, I've started noticing strange bugs as long as I didn't set 1second timeout.
Started digging in deeper, and I've noticed the `UIAlert` gets attached to the `RCTWindow()` mainViewController.
However - since RCTDevLoadingView adds a `keyWindow`, that is the window that will be returned at the time of the call and the window `UIAlert` will be attached to.
To visualise that better - you can take a look at these two frames when app is being loaded:
<img width="371" alt="screen shot 2016-04-20 at 22 02 45" src="https://cloud.githubusercontent.com/assets/2464966/14688596/ae8d292c-0743-11e6-8aeb-e45da391b5b5.png">
<img width="371" alt="screen shot 2016-04-20 at 22 02 58" src="https://cloud.githubusercontent.com/assets/2464966/14688599/b30798e8-0743-11e6-951a-463fe7324c56.png">
AFAIK we do
Closes https://github.com/facebook/react-native/pull/7098
Differential Revision: D3207395
Pulled By: javache
fb-gh-sync-id: f8dca063573ac6f2a0ec497138b2ed0a7b27788b
fbshipit-source-id: f8dca063573ac6f2a0ec497138b2ed0a7b27788b
Summary:When JSC throws an error on startup (e.g. a SyntaxError) or when invoking a method that is not caught by RCTExceptionsManager, we previously just reported is a native error, with a (useless) native stack trace in the redbox. This changes that behaviour to report a JS stacktrace.
The same issue was previously reported here: https://github.com/facebook/react-native/pull/5677
Reviewed By: majak
Differential Revision: D3037387
fb-gh-sync-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
fbshipit-source-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
Summary:All UIManager operations that affect the view hierarchy are executed via the `addUIBlock:` method, which queues them up to be executed after layout has been completed on the shadow queue.
One of the most expensive view operations is view creation, but since this doesn't actually depend on layout, there's no reason to delay it until the shadow operations have finished.
This diff modifies the `createView` method to dispatch view creation directly to the main thread instead of adding it to the UIBlock queue. This seems to result a measurable improvement in TTI.
(Credit to astreet, for implementing the same idea on Android, and thanks to oli for telling me about it!)
Reviewed By: javache
Differential Revision: D3155709
fb-gh-sync-id: 3ad1da9a8fee687aa7e0e023d668192d94dba340
fbshipit-source-id: 3ad1da9a8fee687aa7e0e023d668192d94dba340
Summary:* Add ability to configure the app that should open when starting debugging
axemclion discussed this feature with tadeuzagallo and martinbigio on: https://github.com/facebook/react-native/issues/5051
Closes https://github.com/facebook/react-native/pull/5683
Reviewed By: martinbigio
Differential Revision: D2971497
Pulled By: mkonicek
fb-gh-sync-id: 91c3ce68feed989658124bb96cb61d03dd032599
fbshipit-source-id: 91c3ce68feed989658124bb96cb61d03dd032599
Summary:If you're working on an app that needs to support landscape, reloading the app causes the iPhone simulator to reset its orientation to portrait every time the `RCTDevLoadingView` shows up. This is because it sets the root VC to `RCTModalHostViewController`, which currently supports only portrait orientations on iPhone. Changing the root view to a vanilla `UIViewController` fixes the issue.
**Steps to Reproduce**
1. Create a blank RN project: `react-native init RNTest`
2. Open it up and run it.
3. Rotate to landscape `Cmd+Right Arrow`.
4. Reload by pressing `Cmd+R`.
**Expected**
The simulator stays in landscape mode.
**Actual**
The simulator goes back to portrait.
Closes https://github.com/facebook/react-native/pull/6765
Differential Revision: D3127339
Pulled By: javache
fb-gh-sync-id: e2543c90c8d116307dcefa89a417447c1f1a327f
fbshipit-source-id: e2543c90c8d116307dcefa89a417447c1f1a327f
Summary:The 200ms timeout was causing resource issues and causing a lot of overhead when you're not running the devtools, since it will basically create a new socket every 200ms.
Also clean up the way we do logging so it's completely compiled out in prod, and standardize all the names we use for threading to lowercase react.
Reviewed By: frantic
Differential Revision: D3115975
fb-gh-sync-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
fbshipit-source-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
Summary:The packager url for the persistent connection relied on a port
in the bundleURL, so we need to insert a sensible default. Otherwise,
issues occur: https://github.com/facebook/react-native/issues/6581
Reviewed By: bestander
Differential Revision: D3113034
fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
Summary:Changing app state back to 'background' for UIApplicationWillEnterForegroundNotification.
On iOS we use the 'background' app state to determine whether a notification was tapped to foreground the app vs. received while app was already active. The PR https://github.com/facebook/react-native/pull/6379 changed RCTAppState so that it returned 'active' when app was being foregrounded from a notification; this changes it back to 'background' so that we can distinguish between the two cases again
Reviewed By: hedgerwang
Differential Revision: D3078746
fb-gh-sync-id: 8b5e9118a7e14f15871bfb68e9f85d20108b1faf
shipit-source-id: 8b5e9118a7e14f15871bfb68e9f85d20108b1faf
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:Because the source of truth for backgroundColor is the shadow view, it's possible for the default RCTView backgroundColor to get overwritten by the current shadowView backgroundColor when the view is first created. This overridden value will then be used as the default whenever the background color is reset, which may not be be appropriate for other components that use RCTView.
This diff fixes the bug by ensuring that the view props (and therefore the default color) are set *before* the background color is propagated from the shadowView.
Reviewed By: furdei
Differential Revision: D3064128
fb-gh-sync-id: ac36007c094c7201a5c4fd93399dee4d3eb9a043
shipit-source-id: ac36007c094c7201a5c4fd93399dee4d3eb9a043
Summary:The AlertViewIOS component takes in a 'defaultValue' for the text input but never actually sets it, this PR actually sets the value.
Closes https://github.com/facebook/react-native/pull/6257
Differential Revision: D3052412
Pulled By: nicklockwood
fb-gh-sync-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
shipit-source-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
Summary:**Motivation**
AppStateIOS never currently returns `inactive` as a possible state. I had a requirement that when inactive, certain portions of the app should be blacked out in accordance with compliance rules. This is not possible currently, due to `inactive` never being returned. This PR fixes that.
**Test plan**
All base tests are passing. Are there AppState specific tests in place at the moment that I'm missing?
**Demonstration**
Closes https://github.com/facebook/react-native/pull/6379
Differential Revision: D3035530
Pulled By: nicklockwood
fb-gh-sync-id: 93deccc8184816809926dca8a95f2bebd1434987
shipit-source-id: 93deccc8184816809926dca8a95f2bebd1434987
Summary: If we're compiling with `-Wunused-variable` and `__IPHONE_OS_VERSION_MIN_REQUIRED` >= 8.0, this would cause an build error.
Reviewed By: javache, majak
Differential Revision: D3019904
fb-gh-sync-id: d4482d7d070f8d896acd44b03ebc70bacd9f2f3f
shipit-source-id: d4482d7d070f8d896acd44b03ebc70bacd9f2f3f
Summary:This commit modifies the jsSchedulingOverhead warning to only fire if the JS clock is more than 5 seconds ahead of the native clock. This fixes the issue in #1598 for the common case when there's only a minor difference between the two clocks, while still keeping a sanity check if they're extremely off.
cc nicklockwood tadeuzagallo
Closes https://github.com/facebook/react-native/pull/5731
Differential Revision: D3014985
Pulled By: tadeuzagallo
fb-gh-sync-id: bf57e48b7d97ad02d2aefb6e5aac845824a6fdb0
shipit-source-id: bf57e48b7d97ad02d2aefb6e5aac845824a6fdb0
Summary:The UICollectionView example is actually my use-case, which is discussed in a
bit more detail [here](https://github.com/alloy/ReactNativeExperiments/issues/2).
----
This is useful when wrapping native iOS components that determine their
own suggested size and which would be too hard/unnecessary to replicate
in the shadow view. For instance a `UICollectionView` that after layout
will update its `contentSize`, which could be used to suggest a size to
the shadow view.
The reason for adding it to -[RCTShadowView setFrame:] is mainly so it
can be used via the existing -[RCTUIManager setFrame:forView:] API and
because it might not be a feature you want to expose too prominently.
An origin of `{ NAN, NAN }` is used as a sentinel to indicate that the
frame should be used as a size suggestion. The size portion of the rect
may contain a `NAN` to skip that dimension or a suggested value for the
dimension which will be used if no explicit styling has been assigned.
Examples:
* Without any expl
Closes https://github.com/facebook/react-native/pull/6114
Differential Revision: D2994796
Pulled By: nicklockwood
fb-gh-sync-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
shipit-source-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
Summary: The module initialization process is complex and full of race conditions. This diff adds a set of unit tests that verify that modules setup happens in the correct order, and enforces all the various conditions for main/background init.
Reviewed By: javache
Differential Revision: D2994145
fb-gh-sync-id: 92ea84508cdeeb280ff0fb9e9b2dffa8dbc37e66
shipit-source-id: 92ea84508cdeeb280ff0fb9e9b2dffa8dbc37e66
Summary: When embedding in a hybrid app, we sometimes present new modal views or windows that have a different frame from the original root view. This API allows us to get coordinates in the application's window frame, which should be valid in any fullscreen view.
Reviewed By: majak
Differential Revision: D2939827
fb-gh-sync-id: 06b93cc2cb3519a25819c6efa445c779314dd673
shipit-source-id: 06b93cc2cb3519a25819c6efa445c779314dd673
Summary:The `RCTDevMenu.hotLoadingAvailable` check always returned YES if `bridge.bundleURL` was nil. This caused the `setHotLoadingEnabled:` method to repeatedly reload the bridge, resulting in the following tests failing:
`- [RCTBridgeTests testHookRegistration];`
`- [RCTBridgeTests testCallNativeMethod];`
Also, the `RUN_RUNLOOP_WHILE()` macro did not actually assert when timing out, and the logic in `- [RCTBridgeTests tearDown];` was broken in such a way that tests would always take 5 seconds to run (and then timeout silently). This adds an assertion, and removes the broken nil check for `jsExecutor`.
Reviewed By: majak
Differential Revision: D2988885
fb-gh-sync-id: 91307585ac8acb0181f0cddeeddf6cb4b198e4fe
shipit-source-id: 91307585ac8acb0181f0cddeeddf6cb4b198e4fe
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: 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:
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:
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:
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:
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
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:
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
Janic Duplessis
Pieter De Baets
Mike Grabowski
Martin Kralik
Ian Yu-Hsun Lin
Nick Lockwood
digeff
Tisho Georgiev
Walter Luh
Emily Janzer
Alexey Lang
Morgan Pretty
Ken Wheeler
Mark Wang
Martín Bigio
Kyle Corbitt
Eloy Durán
Dave Miller
Satyajit Sahoo
tantan
