Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
Added a button to the iOS Red Box to enable copying of the error and stack trace to the clipboard to make it easier to paste the error and stack into bug reports or other text windows. Clicking the Copy button on the bottom of the RedBox screen or pressing Cmd-Option-C keyboard shortcut in the simulator will copy the full stack trace as text to the iOS pasteboard and when in the simulator you can then hit Command-C to get the text to the Mac's pasteboard for pasting in your favorite reporting/tracking app.
No tests for this change - I don't see any tests to extend for the RCTRedBoxWindow class. No impact on APIs or core React Native functionality. I validated it by running test React Native apps with red box errors and both hitting the copy button or using the command key shortcut in the emulator to get the text of the stack to the iOS pasteboard.
Closes https://github.com/facebook/react-native/pull/7557
Differential Revision: D3311743
Pulled By: javache
fbshipit-source-id: 76d1ac8ab93f40696c6a2369dae2245194db095a
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary: Having UI modules access the shadowQueue via UIManager.methodQueue is fragile and leads to race conditions in startup, sometimes resulting in an error where the methodQueue is set twice, or not at all.
Reviewed By: javache
Differential Revision: D3304890
fbshipit-source-id: 7198d28314dbec798877fcaaf17ae017d50157e9
Summary:
The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.
This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.
This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.
I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.
Reviewed By: vjeux
Differential Revision: D3292361
fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
Summary:
Currently, `7 << 16` is used as the animation easing function for both the showing and hiding of the keyboard.
Instead, `7 << 16` should be used for showing the keyboard and `6 << 16` for hiding the keyboard.
For details, see: http://stackoverflow.com/questions/18870447/how-to-use-the-default-ios7-uianimation-curve/19439283#19439283
**Test plan (required)**
Testing animating the position of a view to coordinate with the keyboard hiding and showing and it looks good.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7372
Differential Revision: D3300464
Pulled By: nicklockwood
fbshipit-source-id: 3fdc161f709de11deb7de511aad28767f5d80bd6
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Summary:
Previously, if a module implemented `setBridge:` we assumed that it needs to be initialised on the main thread. This assumption was not really warranted however, and it was a barrier to deferring module initialization.
This diff tweaks the rules so that only modules that override `init` or `constantsToExport**` are assumed to require main thread initialization, and others can be created lazily when they are first used.
WARNING: this will be a breaking change to any 3rd party modules that are assuming `setBridge:` is called on the main thread. Those modules should be rewritten to move any code that requires the main thread into `init` or `constantsToExport` instead.
`**` We will also be examining whether `constantsToExport` can be done lazily, but for now any module that uses it will still be created eagerly when the bridge starts up.
Reviewed By: javache
Differential Revision: D3240682
fb-gh-sync-id: 48f309e3158bbccb52141032baf70def3e609371
fbshipit-source-id: 48f309e3158bbccb52141032baf70def3e609371
Summary:
Hi,
I noticed touching stack frames from the red box when running from an iOS device wouldn't open my editor (was working fine from the simulator).
Here's a fix.
Let me know if everything looks correct.
Thanks,
Closes https://github.com/facebook/react-native/pull/7088
Differential Revision: D3235102
Pulled By: javache
fb-gh-sync-id: 06e6c3f9164e987ea9bf71d16fe360dc37036c8d
fbshipit-source-id: 06e6c3f9164e987ea9bf71d16fe360dc37036c8d
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
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:
fixes#3106
Having -1 would trigger callback one frame early causing it to be ignored on the next frame.
Closes https://github.com/facebook/react-native/pull/3190
Reviewed By: svcscm
Differential Revision: D2783700
Pulled By: mkonicek
fb-gh-sync-id: 02070f70915055aec3b1543a8d553f2680438611
Summary:
public
Most of the time - especially during app startup - when we call UIManager.manageChildren(), we are actually just adding the first set of children to a newly created view.
This case is already optimized for in the JS code, by memoizing index arrays at various sizes, but this is not especially efficient since it is still sending an array of indices with each call that could be easily inferred on the native side instead.
I've added a hybrid native/JS optimization that improves the performance for this case. It's not a huge win in terms of time saved, but benchmarks show improvements in the ~1% range for several of the app startup metrics.
Reviewed By: tadeuzagallo
Differential Revision: D2757388
fb-gh-sync-id: 74f0cdbba93af2c04d69b192a8c2cc5cf429fa09
Summary:
public
Thanks to the new lazy initialization system for modules, `RCTDidCreateNativeModules` no longer does what the name implies.
Previously, `RCTDidCreateNativeModules` was fired after all native modules had been initialized. Now, it simply fires each time the bridge is reloaded. Modules are created on demand when they are needed, so most of the assumptions about when `RCTDidCreateNativeModules` will fire are now incorrect.
This diff deprecates `RCTDidCreateNativeModules`, and adds a new notification, `RCTDidInitializeModuleNotification`, which fires each time a module a new module is instantiated.
If you need to access a module at any time you can just call `-[bridge moduleForClass:]` and the module will be instantiated on demand. If you want to access a module *only* after it has already been instantiated, you can use the `RCTDidInitializeModuleNotification` notification.
Reviewed By: tadeuzagallo
Differential Revision: D2755036
fb-gh-sync-id: 25bab6d5eb6fcd35d43125ac45908035eea01487
Summary:
public
A lot of the core modules have to use private methods in the bridge, specially
since the `RCTBatchedBridge` interface is never exposed. That was leading to a
lot of different private bridge categories spread across different modules,
which makes harder to identify which modules are affected by private API changes.
Replace all the categories with a single private header.
Reviewed By: nicklockwood
Differential Revision: D2757564
fb-gh-sync-id: 793158b9082d542b74a6094ed0db4d5dc3a88f78
Summary:
A component can be backed by native "node" that can change its internal state, which would result in a new UI after the next layout. Since js has no way of knowing that this has happened it wouldn't trigger a layout if nothing in js world has changed. Therefore we need a way how to trigger layout from native code.
This diff does it by adding methods `layoutIfNeeded` on the uimanager and `isBatchActive` on the bridge.
When `layoutIfNeeded` is called it checks whether a batch is in progress. If it is we do nothing, since at it's end layout happens. If a batch is not in progress we immidiately do layout.
I went with the easiest way how to implement this - `isBatchActive` is a public method on the bridge. It's not ideal, but consistent with other methods for modules.
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2748896
fb-gh-sync-id: f3664c4af980d40a463b538e069b26c9ebad6300
Summary:
public
This diff replaces the RegEx module method parser with a handwritten recursive descent parser that's faster and easier to maintain.
The new parser is ~8 times faster when tested on the UIManager.managerChildren() method, and uses ~1/10 as much RAM.
The new parser also supports lightweight generics, and is more tolerant of white space.
(This means that you now can – and should – use types like `NSArray<NSString *> *` for your exported properties and method arguments, instead of `NSStringArray`).
Reviewed By: jspahrsummers
Differential Revision: D2736636
fb-gh-sync-id: f6a11431935fa8acc8ac36f3471032ec9a1c8490
Summary:
public
Currently, we wait to invoke `-flushUIBlocks` until the JavaScript batch to native has completed. This means we may be waiting an unnecessarily long time to perform view hierarchy changes and prop changes.
By instead invoking this after each chunk of enqueued UI blocks, we can perform some updates more eagerly, increasing our utilization of the main thread while splitting up the amount of time we spend running upon it.
This shouldn't affect layout, which is still tied to `-batchDidComplete`, so any visual inconsistencies should be limited to prop changes, which seems acceptable for the dramatic improvement in performance.
Reviewed By: javache
Differential Revision: D2658552
fb-gh-sync-id: 6d4560e21d7da1b02d2f30d1860d60735f11c4b5
Summary: Request from issue #3893
* Added support for `secure-text` and `login-password` types to AlertIOS.
* Fixed and extended the cancel button highlighting functionality, which was broken at some point
* Added localization for default `OK` and `Cancel` labels when using UIAlertController
Closes https://github.com/facebook/react-native/pull/4401
Reviewed By: javache
Differential Revision: D2702052
Pulled By: nicklockwood
fb-gh-sync-id: cce312d7fec949f5fd2a7c656e65c657c4832c8f
Summary: There is no point in using `updateLayout` when we have `didSetProps`.
The only a bit risky part is calling `dirtyLayout` in `setFrame:forView:` instead of `updateLayout`,
but since setting frame shouldn't really change border/margin/padding it should be ok.
Depends on D2699512.
public
Reviewed By: nicklockwood
Differential Revision: D2700012
fb-gh-sync-id: a7c33b3b4e3ddc195bebebb8b03934131af016fb
Summary: public
The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.
This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.
The rules are now as follows:
* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.
These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.
I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:
Out of the 65 modules included in UIExplorer:
* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand
Reviewed By: jspahrsummers
Differential Revision: D2677695
fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
Summary: public
Ability to efficiently remove all keys with a particular prefix
Reviewed By: tadeuzagallo
Differential Revision: D2658741
fb-gh-sync-id: 3770f061c83288efe645162ae84a9fd9194d2fd6
Summary: If a redbox error is too long it's not shown at all:
{F24443416}
This diff truncates it to its first 10000 chars, which should be good enough:
{F24443417}
The reason is a limitation of UILabel which backs text property on the used UITableViewCell.
Ideally we would use a custom cell with UITextView, but I don't feel there is any value in displaying super long error messages in a redbox.
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2690638
fb-gh-sync-id: d9b3fcecd2602e8c2618afe1bb97221c2e506605
Summary: public
We were calling constantsToExport twice for every ViewManager, and including two copies of the values in __fbBatchedBridgeConfig. This diff removes the copy from UIManager and then puts it back on the JS side.
Reviewed By: tadeuzagallo
Differential Revision: D2665625
fb-gh-sync-id: 147ec4bfb404835e3875964476ba233d619c28aa
Summary: public
RCTPasteboard is a very basic API for writing strings to the pasteboard. Useful for implementing "copy to clipboard" functionality.
Reviewed By: astreet
Differential Revision: D2663875
fb-gh-sync-id: 8d0ecd824c3e9fe135b02201d21d0dab1907c329
Summary: public
In iOS < 9, inserting a nil object into NSMutableDictionary crashes. It is valid for come components to return a nil shadowView (e.g. ART nodes), and this was crashing on iOS 8.
Reviewed By: jspahrsummers
Differential Revision: D2658309
fb-gh-sync-id: 7abf9273708cc03c3b6307b69ba11c016b471fbe
Summary: public
RCTImagePicker (aka ImagePickerIOS) was previously displaying UI from a random thread, which is unsafe. This diff forces it to execute on the main thread instead.
Reviewed By: jspahrsummers
Differential Revision: D2657465
fb-gh-sync-id: 3c0fa6935061ccaa3e6ce649b4e3e8ad8c701384
Summary: This queue processes layout and user interface updates, so it should have as high a quality-of-service/priority as possible.
public
Reviewed By: javache
Differential Revision: D2641837
fb-gh-sync-id: 934686f7969b43101af183148d67ff7be4bdf660
Summary: public
The WebView executor has no benefits compared to the JSC executor (slower, no extra debugging tools...),
and it's pretty hacky (since it injects the code in a script tag we have to check for tags in the comments and etc...).
Reviewed By: nicklockwood, javache
Differential Revision: D2636465
fb-gh-sync-id: 0d0f8a59e2c12fe7905b02060b3938c894d2802b
Summary: public
Rename it to `RCT_PROFILE_(BEGIN|END)_EVENT` to make it clearer that it's a macro,
since it has special behaviours.
Reviewed By: jspahrsummers
Differential Revision: D2631542
fb-gh-sync-id: 629c139462c4aa3582f719b14482017d13676e33
Summary: public
There were some old markers that are now automatically inject and now are no longer necessary (+ one that was missing an end call :( ))
Reviewed By: javache
Differential Revision: D2625901
fb-gh-sync-id: 4c4c9d6b4e8e2b4bdb9c64fde01000b0ca2e9f47
Summary: public
Add RCTFatal for reporting fatal runtime conditions. This centralizes failure handling to one function and allows you to customize how they should be handled. RCTFatal will be logged to the console and as a redbox and will also be triggered by fatal exceptions coming from RCTExceptionsManager.
Note that there is no RCTLogFatal, since just logging the fatal condition does not allow us to handle it consistently.
Reviewed By: nicklockwood
Differential Revision: D2615490
fb-gh-sync-id: 7d8e134419e10a8fb549297054ad955db3f6bee0
Summary: I was getting the following error when running `testAsyncStorageTest`
```
uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (NSError)'
```
nicklockwood pointed out that it might be because we're attempting to send a `NSError *` over the bridge at some point. So I went looking for cases where that might happen and found this instance.
public
Reviewed By: jingc
Differential Revision: D2619240
fb-gh-sync-id: dc26ec268f976fec44f2804831398d3b01ab6115
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary: public
The UIManager had a lock around the enqueued ui blocks, but now all the operations
should happen on the shadow thread, so I added assertions to it and removed the
locks.
Reviewed By: nicklockwood
Differential Revision: D2605760
fb-gh-sync-id: e1bc649f759502e7e9fd059932e0cba38dba05bf
Summary: There is no point in dispatching to main thread if there is nothing to do there.
This place gets called basically any time a repeating js timer fires, which doesn't imply UI changes (although usually that's why people setup timers).
Combined with previous diffs that makes us not generate empty blocks (nil instead), this could be minor perf win in some rare cases.
This also changes semantic of `reactBridgeDidFinishTransaction` call a bit. Previously it was done no matter if UI has changed or not.
I think it should be safe, since seems like callees really care only about views being laid out.
Depends on D2571166. (not strictly speaking)
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2571188
fb-gh-sync-id: 02d52e4615475072c3c27226e67c431a667ec990
Summary: Same as in previous diffs. Gets us into a better place to know if we really have UI updates and it's marginally more efficient.
Depends on D2571143. (not really)
public
Reviewed By: nicklockwood
Differential Revision: D2571166
fb-gh-sync-id: e8f34521ec2e12156a49f1cd655e92df1db34fca
Summary: Previously `_bridgeTransactionListeners` were informed about `reactBridgeDidFinishTransaction` inside of one of the UI blocks.
That seems pretty arbitrary, doesn't really mean a "transaction" is really over (assuming transaction means all UI updates) and even when that block does nothing we still need to call these listeners, since there could be other UI blocks generated somewhere else!
So I've moved this call to a place that seemed better (=after all UI blocks are done), since all listeners are interested in knowing when layout has happened.
public
Reviewed By: nicklockwood
Differential Revision: D2571122
fb-gh-sync-id: 62be03ebc4353d6f6318c9765079b87b07483be2
Summary: public
Kill `RCTPerfStats` and introduce the new `RCTPerfMonitor`, including memory
usage, JSC heap size, number of RN views in screen, FPS (both on UI and JS threads)
and more to come.
It removes all the previous traces that were previous spread across the bridge
and the dev menu and moves everything to be more contained, so the whole thing
can be safely striped in production.
Reviewed By: nicklockwood
Differential Revision: D2575158
fb-gh-sync-id: 6a6d0c4422adbddeeefddd32ec3409a7095ff2a9
Summary: While we shouldn't invoke `bridge.devMenu` in production, doing it will result into a crash.
1. `devMenu` internally calls `RCTBridgeModuleNameForClass([RCTDevMenu class])`
2. `RCTBridgeModuleNameForClass()` calls `moduleName`
3. In the release code `RCTDevMenu` doesn't export the `moduleName` class method.
Closes https://github.com/facebook/react-native/pull/2910
Reviewed By: svcscm
Differential Revision: D2550797
Pulled By: tadeuzagallo
fb-gh-sync-id: 5dfbf905e5a02d9fd3b52f8b3d6eefc4e3ff30b2
Summary: public
Benchmarking our startup path has shown we spend a lot of time decoding strings (iPhone 4S / iPhone 5):
* reading a 2MB JS bundle: 35ms / 15ms
* decoding is to an `NSString`: 186ms / 78ms
* transforming that to a `JSString`: 29ms / 10ms
Instead of going through an `NSString` transformation, we generate a null-terminated bundle (0.1ms / 0.05ms to copy the data) and use `JSStringCreateWithUTF8CString` (121ms / 53ms) to generate the string. That makes decoding 70% faster.
Reviewed By: javache
Differential Revision: D2541140
fb-gh-sync-id: 09a016b8edfd46a9b62682c76705564d2024e75e
Summary: @public
This diff implements inline image support for <Text> nodes. Images are specified using <Image> tags, however all properties of the image are currently ignored apart from the source (including width/height styles).
Images are loaded asyncronously, and will trigger a text re-layout when they have loaded.
Reviewed By: @javache
Differential Revision: D2507725
fb-gh-sync-id: 59d0696d00a1bc531915cc35242a16b2dec96e85
Summary: When you reload and create a new bridge, one of the things that happens during setup is that the RCTAccessibilityManager fires a notification. The old bridge would receive this notification from the new bridge's RCTAccessibilityManager, which we don't want, especially because the two are running on different shadow queues.
I believe this led to a gnarly crash in NSConcreteTextStorage because RCTMeasure in RCTShadowText.m was getting called for the old RCTText (getting destroyed) from a notification fired from the new shadow queue. The fix is for the UIManager to handle notifications only from its bridge's RCTAccessibilityManager. See #2001 for the kinds of crashes we were seeing.
Closes https://github.com/facebook/react-native/pull/3279
Reviewed By: @svcscm
Differential Revision: D2521652
Pulled By: @nicklockwood
fb-gh-sync-id: a4ffe3ef8304667727e573e2a2e8b716e1d2f3e1
Summary: This adds workarounds for the code that was preventing React from compiling when linked against an iOS App Extension target.
Some iOS APIs are unavailable to App Extensions, and Xcode's static analysis will catch attempts to use methods that have been flagged as unavailable.
React currently uses two APIs that are off limits to extensions: `[UIApplication sharedApplication]` and `[UIAlertView initWith ...]`.
This commit adds a helper function to `RCTUtils.[hm]` called `RCTRunningInAppExtension()`, which returns `YES` if, at runtime, it can be determined that we're running in an app extension (by checking whether the path to `[NSBundle mainBundle]` has the `"appex"` path extension).
It also adds a `RCTSharedApplication()` function, which will return `nil` if running in an App Extension. If running in an App, `RCTSharedApplication()` calls `sharedApplication` by calling `performSelector:` on the `UIApplication` class. This passes the static analysis check, and, in my opinion, obeys the "spirit of th
Closes https://github.com/facebook/react-native/pull/1895
Reviewed By: @svcscm
Differential Revision: D2224128
Pulled By: @nicklockwood
Summary: - Includes the error cookie with soft exceptions as well since they too can be updated (requires tiny Android change too)
- Passes the error cookie through instead of leaving it unused
Closes https://github.com/facebook/react-native/pull/2198
Reviewed By: @svcscm
Differential Revision: D2455391
Pulled By: @sahrens
Summary:
I'd like this ability as this has a tendency to get in the way of some of the more complex UI pieces I have. Disabling RCT_DEV entirely is too much for me.
Closes https://github.com/facebook/react-native/pull/2451
Github Author: Tj <tfallon@mail.depaul.edu>
Summary:
We currently wait until after views have been updated on the main thread before sending layout events. This means that any code that relies on those events to update the UI will lag the atual layout by at least one frame.
This changes the RCTUIManager to send the event immediately after layout has occured on the shadow thread. This noticably improves the respinsiveness of the layout example in UIExplorer, which now updates the dimension labels immediately instead of waiting until after the layout animation has completed.
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
Add JSC profiler to the dev menu and rename the pre-existent one to systrace.
For now it just outputs to the console, but a better workflow is on the way.
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Summary:
Moved the view creation & property binding logic out of RCTUIManager into a separate RCTComponentData class - this follows the pattern used with the bridge.
I've also updated the property binding to use pre-allocated blocks for setting the values, which is more efficient than the previous system that re-contructed the selectors each time it was called. This should improve view update performance significantly.
Summary:
Dynamic Text Sizes for Text component.
Text gains new prop - allowFontScaling (false by default).
There is also AccessibilityManager module that allows you to tune multipliers per each content size category.
Summary:
The bridge implementation on React Android does not currently support boxed numeric/boolean types (the equivalent of NSNumber arguments on iOS), nor does Java support Objective-C's nil messaging system that transparently casts nil to zero, false, etc for primitive types.
To avoid platform incompatibilities, we now treat all primitive arguments as non-nullable rather than silently converting NSNull -> nil -> 0/false.
We also now enforce that NSNumber * objects must be explicitly marked as `nonnull` (this restriction may be lifted in future if/when Android supports boxed numbers).
Other object types are still assumed to be nullable unless specifically annotated with `nonnull`.
Summary:
Added the ability to turn on and off the network activity indicator using:
```
StatusBarIOS.setNetworkActivityIndicatorVisible(true)
```
and
```
StatusBarIOS.setNetworkActivityIndicatorVisible(false)
```
Also added an example to the UIExplorer example app.
Fix#986
Closes https://github.com/facebook/react-native/pull/2079
Github Author: Mark Miyashita <negativetwelve@gmail.com>
Summary:
RCTNetworkImageView and RCTStaticImage had significant overlap in functionality, but each had a different subset of features and bugs.
This diff merges most of the functionality of RCTNetworkImageView into RCTStaticImage, eliminating some bugs in the former, such as constant redrawing when properties were changed.
I've also removed the onLoadAbort event for now (as it wasn't implemented), and renamed the other events to match the web specs for `<img>` and XHMLHttpRequest. The API is essentially what Adobe proposed here: http://blogs.adobe.com/webplatform/2012/01/13/html5-image-progress-events/
The following features have not yet been ported from RCTNetworkImageView:
- Background color compositing. It's not clear that this adds much value and it increases memory consumption, etc.
- Image request cancelling when images are removed from view. Again, it's not clear if this is a huge benefit, but if it is it should be combined with other optimisations, such as unloading offscreen images.
(Note that this only affects the open source fork. For now, internal apps will still use FBNetworkImageView for remote images.)
Summary:
These are the changes needed for full interop with the (as yet unreleased) new
version of React Devtools.
- the on-device inspector is minimized when devtools is open
- devtools highlight -> device and device touch -> devtools select works
- editing react native styles :)
Summary:
Dynamic Text Sizes for Text component.
Text gains new prop - allowFontScaling (true by default).
There is also AccessibilityManager module that allows you to tune multipliers per each content size category, but predefined multipliers are there.
This could potentially break some apps so please test carefully.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
Summary:
This adds the Keyboard animation type for when you want to animate UI based on the keyboard appearing/disappearing.
Closes https://github.com/facebook/react-native/pull/1366
Github Author: Stanislav Vishnevskiy <vishnevskiy@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Started from here - https://github.com/facebook/react-native/issues/1120. Most functionality for annotations were missing so I started implementing and somehow got caught up until the entire thing was done.
2 new events:
- callout presses (left / right)
- annotation presses
6 new properties for annotations:
- hasLeftCallout
- hasRightCallout
- onLeftCalloutPress
- onRightCalloutPress
- animateDrop
- id
1 new property for MapView
- onAnnotationPress
---
Now the important thing is, that I implemented all of this the way "I would do it". I am not sure this is the 'reacty' way so please let me know my mistakes 😄
The problem is that there is no real way to identify annotations which makes it difficult to distinguish which one got clicked. The idea is to pass a `id` and whether it has callouts the entire way with the annotation. I had to
Closes https://github.com/facebook/react-native/pull/1247
Github Author: David Mohl <me@dave.cx>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
@public
Test Plan: There are tests in `RCTUIManagerTests.m` that test the tag- and index-manipulation logic works. There are various scenarios including add-only, remove-only, and move. In addition, two scenario tests verify that the optimization works by checking the number of views and shadow views after various situations happen.
Summary:
@public
The info about bridge modules (such as id, name, queue, methods...) was spread
across arrays & dictionaries on the bridge, move it into a specific class.
It also removes a lot of information that was statically cached, and now have
the same lifecycle of the bridge.
Also moved RCTModuleMethod, RCTFrameUpdate and RCTBatchedBridge into it's own
files, for organization sake.
NOTE: This diff seems huge, but most of it was just moving code :)
Test Plan:
Tested UIExplorer & UIExplorer tests, Catalyst, MAdMan and Groups. Everything
looks fine.
Summary:
@public
Add marker to show JavaScript download duration + flow arrows to show the origin
of the UI blocks being flushed.
Also fixed the condition on `RCTPerfStats`, UI and JS graphs were being created
at startup time, now they're just created on the first time they're shown.
Test Plan:
The markers:
{F22577660}
To check the FPS graph, enable it on the DevMenu, and it should appear initially
empty, instead of previously filled as before.
Summary:
@public
This removes the last piece of data that was still stored on the DATA section,
`RCT_IMPORT_METHOD`. JS calls now dynamically populate a lookup table simultaneously
on JS and Native, instead of creating a mapping at load time.
Test Plan: Everything still runs, tests are green.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
`-[RCTJavaScriptExecutor executeBlockOnJavaScriptQueue:]` would always `dispatch_async`
for the WebView and WebSocket executors, what caused for any frame aligned dispatch.
Test Plan:
Test the `Timers, TimerMixin` example on UIExplorer, `requestAnimationFrame` was
taking ~33.3ms when debugging, now takes ~16.6ms as expected.
Summary:
@public
setFrame:forRootView: wasn't triggering a batch update, which is required to trigger text update. This meant text wasn't re-displayed after a rotate, only after a touch.
I also found a bug that meant we weren't caching textStorage as much as we could be. Fixed that too.
Test Plan:
* Test <Text> example in UIExplorer and ensure it lays out on rotate.
* Test <Timers> example and verify text is still updating
* Products shouldn't be affected as they have separate text implementation
Summary:
@public
This probably needs more thought - might want to differentiate between console.error and reportError.
Test Plan: console.error and reportError no longer redbox. invariant and RCTLogError still do.
Summary:
@public
There have been multiple instances of confusion about whether a redbox means the
developer did something they shouldn't but things will keep working, or if
something went horribly wrong and the app will crash in prod. This diff
introduces an orange background color to the redbox for `console.error` and
`RCTLogError` to indicate that something bad happened, but that the app will
continue working.
Test Plan:
see orange error for geo permissions:
{F22541375}
Summary:
@public
`RCTDispatchEvent` and `RCTTiming` weren't being paused when there wasn't any
work left to be done.
Test Plan:
Run the timers example - check everything still works as expected
Test the ListView paging example - check scroll events are still fired as expected
Launch UIExplorer, let it idle, and put a break point on `-[RCTBridge dispatchBlock:moduleID:]`,
it should never fire.
Summary:
@public
Bridge modules were being invalidate on the main thread, what could lead to
racing conditions, move the calls to invalidate on happen to the module's
methodQueue
Test Plan: Run the tests
Summary:
@public
ErrorUtils.reportError is intended for reporting handled errors to the
server, like timeouts, which means that we shouldn't shove them in the
developer's face.
Test Plan: add `require('ErrorUtils').reportError(new Error('error'))` and see a useful error message with stack but no redbox. Debugger confirms `reportSoftException` is called but it doesn't do anything yet. `reportFatalError` and throwing exceptions still show redboxes.
Summary:
@public
Right now the profiler shows how long the executor took on JS but doesn't show
how long each of the batched calls took, this adds a *very* high level view of JS
execution (still doesn't show properly calls dispatched with setImmediate)
Also added a global property on JS to avoid trips to Native when profiling is
disabled.
Test Plan:
Run the Profiler on any app
{F22491690}
Summary:
@public
`RCTUIManager` would traverse the whole view hierarchy every time there was any
call from JS to Native to call `reactBridgeDidFinishTransaction` on the views
that would respond to it. This is a deprecated method that is only implemented
by 3 classes, so for now we keep track of these views as they're created and
just iterate through them on updates.
Test Plan:
> NOTE: I tested this on UIExplorer, since the internally none of the classes are used
I tried to keep it simple, so I added the following to the old code:
```
__block NSUInteger count = 0;
UIView *rootView = _viewRegistry[rootViewTag];
RCTTraverseViewNodes(rootView, ^(id<RCTViewNodeProtocol> view) {
count ++;
if ([view respondsToSelector:@selector(reactBridgeDidFinishTransaction)]) {
[view reactBridgeDidFinishTransaction];
}
});
NSLog(@"Views iterated: %zd", count);
```
The output after scrolling 20 sections of the `<ListView> - Paging` example was
```
2015-06-01 00:47:07.351 UIExplorer[67675:1709506] Views iterated: 1549
```
*every frame*
After the change
```
for (id<RCTViewNodeProtocol> node in _bridgeTransactionListeners) {
[node reactBridgeDidFinishTransaction];
}
NSLog(@"Views iterated: %zd", _bridgeTransactionListeners.count);
```
```
2015-06-01 00:51:23.715 UIExplorer[70355:1716465] Views iterated: 3
```
No matter how many pages are loaded, the output is always 3.
Summary:
This adds new development feature to React Native that provides information
about selected element (see the demo in Test Plan).
This is how it works:
App's root component is rendered to a container that also has a hidden layer called
`<InspectorOverlay/>`. When activated, it shows full screen view and captures all
touches. On every touch we ask UIManager to find a view for given {x,y} coordinates.
Then, we use React's internals to find corresponding React component. `setRootInstance`
is used to remember the top level component to start search from, lmk if you have a
better idea how to do this. Given a component, we can climb up its owners tree
to provice more context on how/where the component is used.
In future we could use the `hierarchy` array to inspect and print their props/state.
Known bugs and limitations:
* InspectorOverlay sometimes receives touches with incorrect coordinates (wtf)
* Not integrated with React Chrome Devtools (maybe in followup diffs)
* Doesn't work with popovers (maybe put the element inspector into an `<Overlay/>`?)
@public
Test Plan:
https://www.facebook.com/pxlcld/mn5k
Works nicely with scrollviews
Summary:
@public
Add `RCTAssertThread` to `RCTAssert.h` for convenience when checking the current/queue,
it accepts either a `NSString *`, `NSThread *` or `dispatch_queue_t` as the object to be checked
Also add a check to `-[RCTUIManager addUIBlock:]` - There was a discussion on github (https://github.com/facebook/react-native/issues/1365)
due to the weird behavior caused by calling it from a different thread/queue (it might be added after `batchDidComplete` has been called
and will just be dispatched on the next call from JS to objc)
Test Plan:
Change `-[RCTAnimationExperimentalManager methodQueue]` to return `dispatch_get_main_queue()` and run the 2048 example,
it should dispatch with a helpful message (screenshot on the comments)
Summary:
The RCTRootView creates a underlying RCTRootContentView that was deallocated when
the bridge modules were deallocated. That doesn't work when the bridge is held.
@public
Test Plan:
Launch Groups, put a breakpoint on `-[RCTRootContentView dealloc]`, enter and
leave a group page. It should be called now.
Summary:
Add `AlertIOS.prompt`
It's compatible with the js spec, with the exception that I had to add
a callback param since it's async. Also supports the same button configuration
as `AlertIOS.alert`.
@public
Test Plan:
I've updated the `AlertIOS` example on UIExplorer with every
valid combination of
parameters, so just going through it should be fine.
Summary:
Simply add an `onLayout` callback to a native view component, and the callback
will be invoked with the current layout information when the view is mounted and
whenever the layout changes.
The only limitation is that scroll position and other stuff the layout system
isn't aware of is not taken into account. This is because onLayout events
wouldn't be triggered for these changes and if they are desired they should be
tracked separately (e.g. with `onScroll`) and combined.
Also fixes some bugs with LayoutAnimation callbacks.
@public
Test Plan:
- Run new LayoutEventsExample in UIExplorer and see it work correctly.
- New integration test passes internally (IntegrationTest project seems busted).
- New jest test case passes.
{F22318433}
```
2015-05-06 15:45:05.848 [info][tid:com.facebook.React.JavaScript] "Running application "UIExplorerApp" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF"
2015-05-06 15:45:05.881 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":123,"x":12.5,"width":140.5,"height":18}}
2015-05-06 15:45:05.882 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":122,"width":50,"height":50}}
2015-05-06 15:45:05.883 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":70.5,"x":20,"width":294,"height":204}}
2015-05-06 15:45:05.897 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":206.5,"x":12.5,"width":140.5,"height":18}}
2015-05-06 15:45:05.897 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":70.5,"x":20,"width":294,"height":287.5}}
2015-05-06 15:45:09.847 [info][tid:com.facebook.React.JavaScript] "layout animation done."
2015-05-06 15:45:09.847 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":82,"width":50,"height":50}}
2015-05-06 15:45:09.848 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":110.5,"x":60,"width":214,"height":287.5}}
2015-05-06 15:45:09.862 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":206.5,"x":12.5,"width":120,"height":68}}
2015-05-06 15:45:09.863 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":55,"width":50,"height":50}}
2015-05-06 15:45:09.863 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":128,"x":60,"width":160,"height":337.5}}
```
Summary:
NavigatorIOS supports four new properties:
- **rightButtonImageSource:** The source of an image to display in the top right. This must be a static image since UINavigationController only supports UIImages. Adding support for UIImageViews (or arbitrary views) is more complicated because custom views do not fade on touch and do not have hit slop the same way that UIImage buttons do. Usage: `rightButtonImageSource: ix('ImageName')`
- **backButtonImageSource:** Use a custom image for the back button. This does not replace the back caret (`<`) but instead replaces the text next to it.
- **leftButtonTitle**: Text for the left nav button, which supersedes the previous nav item's back button when specified. The main use case for this is your initial screen/UIVC which has nothing to go back to (since it is the first VC on the stack) but need to display a left button. This does hide the back button if there would have been one otherwise.
- **leftButtonImageSource:** Image source for the left button, super
Closes https://github.com/facebook/react-native/pull/263
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Nick Lockwood
Mike Grabowski
Chris Evans
Adam Comella
Marc Horowitz
Pieter De Baets
Digeff
Jean Regisser
Janic Duplessis
Martin Kralik
Ian Yu-Hsun Lin
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
Jed Lau
John Ku
Tadeu Zagallo
Dan Witte
Justin Spahr-Summers
Christopher Dro
Milen Dzhumerov
Ryan Olson
Natthu Bharambe
Bhuwan Khattar
Pawel Sienkowski
Patrik Tomas Chamelo
Frédéric Sagnes
James Ide
Chace Liang
Jiajie Zhu
Yusef Napora
Martin Konicek
Tj
Alex Kotliarskyi
Matt Mahoney
Alexsander Akers
Vladislav Alexeev
Mark Miyashita
Spencer Ahrens
Dorota Kapturkiewicz
Kevin Gozali
Jared Forsyth
Param Aggarwal
Stanislav Vishnevskiy
David Mohl
Andrei Coman
Andy Street
Georgiy Kassabli
Ben Alpert
Jakub Zika
