Summary:
This change introduces an API, `setAccessibilityFocus`, which moves the screen reader's focus to the passed in element. This causes VoiceOver to announce the element and draw a focus rectangle around it.
Similar functionality is already available in RN Android through the `sendAccessibilityEvent` method. Here's an example of what exists today in RN Android:
```
RCTUIManager.sendAccessibilityEvent(
node,
8 /* TYPE_VIEW_FOCUSED */);
```
Called `setAccessibilityFocus` on a couple of elements to verify that focus does indeed move when VoiceOver is enabled. Additionally, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14169
Differential Revision: D5137002
Pulled By: javache
fbshipit-source-id: 466e8b187e625de7c0f0d36e0400327dcd8d192a
Summary:
Apps commonly provide their own rage-shake menus or behaviors, including in dev builds where the dev menu is enabled on shake. Rather than try to override these settings via native code, it can be helpful to let the app define when to show the menu via the bridge.
See recent discussion in https://github.com/facebook/react-native/issues/1054
Closes https://github.com/facebook/react-native/pull/13563
Differential Revision: D4928745
Pulled By: javache
fbshipit-source-id: a5b30e1b198780bb560e1a6d528f727b3b7d4cb7
Summary:
There was no easy way to pull up the dev menu in the tvOS simulator
Run the UIExplorer demo and press cmd+d to bring up the menu
Closes https://github.com/facebook/react-native/pull/13584
Differential Revision: D4916967
Pulled By: javache
fbshipit-source-id: 27f50031f65f35dad46ad5ade7b52c7d350b31a2
Summary:
Motivation: Similar to https://github.com/facebook/react-native/pull/13242 - the application will crash with `[NSNull lastPathComponent]: unrecognized selector sent to instance` if a stack frame with no filename makes it to RCTRedBox.
Closes https://github.com/facebook/react-native/pull/13360
Differential Revision: D4848980
Pulled By: javache
fbshipit-source-id: dc506f2ba39c2d4d68982b56a6e765a19dc048b0
Summary:
Pair `reactWillMakeFirstResponder` and `reactDidMakeFirstResponder` was replaced with just `reactFocus` method
which is supposed to incapsulate all "focus" and "focus-later-if-needed" functionality.
Reviewed By: mmmulani
Differential Revision: D4664626
fbshipit-source-id: 8d3b7935ca26d32ba1d1826a585cce0396fcc885
Summary:
…th RCTSharedApplication()
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
Using React Native latest version with Cocoapods 1.2.0 causes the following error inside iOS app extensions
> /react-native/React/Modules/RCTAccessibilityManager.m:67:70: ‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
Moving the use of [UIApplication sharedApplication] to RCTSharedApplication() which is safe on app extension
- [ ] Provide a **test plan** demonstrating that the code is solid.
I am not sure how to test such that all the features which touch the modified code are tested.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
Using React Native latest v
Closes https://github.com/facebook/react-native/pull/13227
Differential Revision: D4816338
Pulled By: javache
fbshipit-source-id: e3e3c77882990ad1817b0b633521cff52571ecd0
Summary:
This fixes a bug that causes properties to keep stale values because they were not restored to their default after being removed when their value was controlled by native animated.
To fix this we restore default values in `disconnectFromView` by updating views with null values for all props that we modified previously. However this causes another issue where we lose any props that were set by the normal process because NativeAnimated operations are always executed after UIManager operatations. To fix this I added a way to hook into UIManager view updating process to be able to execute NativeAnimated operations either before or after updating native views.
In the case of disconnecting we want to do it before updating views so that it does: Value changed by native animated -> value restored to default -> (optional) value updated by normal prop.
This PR also depends on #10658.
**Test plan**
Tested that this fixed a particular bug in an app that uses ex-navigation + native animations where a navbar w
Closes https://github.com/facebook/react-native/pull/11819
Differential Revision: D4752566
Pulled By: javache
fbshipit-source-id: 68ee28200ffeba859ae1b98ac753bd7dcb8910f0
Summary:
Various fixes of xcode projects and cleaning up some warnings
Closes https://github.com/facebook/react-native/pull/13109
Differential Revision: D4762652
Pulled By: lacker
fbshipit-source-id: b452976a58962439de4adecc8e703264af40cb38
Summary:
Motivation: Fixes Xcode warning `Ivar '_websocketExecutorName' which backs the property is not referenced in this property's accessor` which shows up because this property has no setter (and is never set anywhere).
Closes https://github.com/facebook/react-native/pull/12639
Differential Revision: D4745437
Pulled By: javache
fbshipit-source-id: 3ab4b0df62f90adc2b62d891197dc783e07da4e3
Summary:
While working with `RCTEventEmitter` I noticed that if an event is emitted before `_listenerCount` is updated, it will not go through because the listeners count hasn't been updated. Moving the count update before the invokation of `startObserving` and `stopObserving` fixes the issue. Same way if you remove the last listener and an event is fired before the count is updated (while it shouldn't be fired).
**Test plan (required)**
An easy test to demonstrate it is to implement `startObserving` to synchronously fire an event. Without the change, a warning is thrown, with the change, the event is fired. Not very strong on Obj-C here and I didn't know how to mock out the native stuff. Would be glad to write a failing unit test tho :)
Closes https://github.com/facebook/react-native/pull/11907
Differential Revision: D4738965
Pulled By: javache
fbshipit-source-id: cf175051be5b9c5de761d3dcd290560e1639b05e
Summary:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
The PR #11613 (0.43) removed this missing `toggleElementInspector` event send when `jsLoaded` in DevMenu (Now is DevSettings), it should open the inspector if `isElementInspectorShown` is true when we reload JS.
The dev menu text `Show / Hide Inspector` is dependent on `isElementInspectorShown` bool value.
([This behavior in 0.42](https://github.com/facebook/react-native/blob/0.42-stable/React/Modules/RCTDevMenu.mm#L436-L442))
Manual testing in UIExplorer:
* Open the dev menu and click `Show Inspector`
* Open the dev menu and click `Reload JS`
* The built-in inspector should keep open (dev menu text: `Hide Inspector`)
Closes https://github.com/facebook/react-native/pull/12999
Differential Revision: D4738959
Pulled By: javache
fbshipit-source-id: b3f584db51aa0e1b463c52003967b00bcd81bc99
Summary:
Several things:
* The mess with insets was fixed. Previously we tried to compensate the insets difference with `UITextField` by adjusting `textContainerInset` property, moreover we delegated negative part of this compensation to the view inset. That was terrible because it breaks `contentSize` computation, complicates whole insets consept, complicates everything; it just was not right. Now we are fixing the top and left inset differences in different places. We disable left and right 5pt margin by setting `_textView.textContainer.lineFragmentPadding = 0` and we introduce top 5px inset as a DEFAULT value for top inset for common multiline <TextInput> (this value can be easilly overwritten in Javascript).
* Internal layout and contentSize computations were unified and simplified.
* Now we report `intrinsicContentSize` value to Yoga, one step before auto-expandable TextInput.
Depends on D4640207.
Reviewed By: mmmulani
Differential Revision: D4645921
fbshipit-source-id: da5988ebac50be967caecd71e780c014f6eb257a
Summary:
The `UIManager` already has a lot of responsibilities and is deeply
tied with React Native's view architecture. This diff separates out a
`DeviceInfo` native module to provide information about screen dimensions and
font scale, etc.
Reviewed By: fkgozali
Differential Revision: D4713834
fbshipit-source-id: f2ee93acf876a4221c29a8c731f5abeffbb97974
Summary:
Moving setting `availableSize` for `RCTRootShadowView` on earlier stage allows to prevent situations where `availableSize` is not specified yet, but Yoga layout is already happening.
Because `availableSize` equals {infinity, infinity} by default (in this case), Yoga returns a lot of nodes with infinit metrics, which confises UIKit.
Reviewed By: mmmulani
Differential Revision: D4672170
fbshipit-source-id: f9d8c84799dcbdb6b9230ddef6284d84df268833
Summary:
A related Android PR is #11008.
Font scale was exposed through:
- The `getContentSizeMultiplier` method
- The `didUpdateContentSizeMultiplier` event
These are now deprecated. The reason is that there was already an API that exposed font scale. However, it was Android only. We now expose font scale through that API on iOS as well. Specifically:
- Font scale is now available as `PixelRatio.getFontScale()`.
- The `change` event on the `Dimensions` object now fires when font scale changes.
This change also adds support for `Dimensions.get('screen')` on iOS. Previously, only `Dimensions.get('window')` was available on iOS. The motivation is that, [according to this comment](https://github.com/facebook/react-native/pull/11008#issuecomment-275123609), we'd like to deprecate `window` dimensions in favor of `screen` dimensions in the future.
**Test plan (required)**
Verified that `PixelRatio.getFontScale()` and the `change` event work properly in a test app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12268
Differential Revision: D4673642
Pulled By: mkonicek
fbshipit-source-id: 2602204da6998a96216e06f5321f28f6603e4972
Summary: RCTDevSettings incorrectly assigned "bad" executor-override class to the executor instead of checking if the class exists before assigning it. It should really check if the class exists, and fallback to defaults otherwise.
Reviewed By: mmmulani, yungsters
Differential Revision: D4655926
fbshipit-source-id: 48c8fe28f22aaa8430752411ce5e6e858dbd4b32
Summary:
* The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability.
It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development.
* I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec.
Closes https://github.com/facebook/react-native/pull/12602
Differential Revision: D4621021
Pulled By: ericvicenti
fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
Summary:
Nothing actually changed except the deprecation.
Existed `intrinsicSize` was already implemented as `intrinsicContentSize` and this change only removes redundancy.
Moreover, we do not need `rootViewDidChangeIntrinsicSize` delegate method anymore; this is now mentioned in its description.
Depends on D4577890
Reviewed By: mmmulani
Differential Revision: D4589344
fbshipit-source-id: 16ed62cbf6bf72678bd7f7c11d4812c5aa36c743
Summary:
This decouples non-UI logic from RCTDevMenu into a new module RCTDevSettings.
**Motivation**: This allows developers to change dev settings without depending on the built-in dev menu, e.g. if they want to introduce their own UI, or have other devtools logic that doesn't depend on an action sheet.
It also introduces the RCTDevSettingsDataSource protocol for storing dev tools preferences. This could allow a developer to implement alternative behaviors, e.g. loading the settings from some other config, changing settings based on the user, deciding not to persist some settings, or something else.
The included data source implementation, RCTDevSettingsUserDefaultsDataSource, uses NSUserDefaults and is backwards compatible with the older implementation, so **no workflows or dependent code will break, and old saved settings will persist.**
The RCTDevMenu interface has not changed and is therefore also backwards-compatible, though
some methods are now deprecated.
In order to ensure that RCTDevSettings
Closes https://github.com/facebook/react-native/pull/11613
Reviewed By: mmmulani
Differential Revision: D4571773
Pulled By: javache
fbshipit-source-id: 25555d0a6eaa81f694343e079ed02439e5845fbc
Summary:
Now things look much more clear, I hope.
This diff:
* Introduces new property of `RCTRootShadowView` `availableSize` which represents exactly what we transmit to layout engine;
* Illuminates conflict between logical `availableSize` and explicitly specified size of DOM node (current `size`);
* Splits overcomplicated `setSize:forView:` method into two unrelated ones;
* Changes actual values of `RCTRootViewSizeFlexibility` enum constants for simpler usage;
* Completely removes `sizeFlexibility` concept from `RCTRootShadowView` (in favor of special values of `availableSize`);
* Makes the code clearer finally.
This is beginning of big effort to improve `RCTRootView` and co.
Reviewed By: mmmulani
Differential Revision: D4562834
fbshipit-source-id: f5baaf2859ea430d44645a6b5d35f222f15a668e
Summary:
Motivation:
* `RCTShadowView`'s `frame` property actually represents computed layout of the view. We must not use it as a setter for yoga node styles;
* Using `frame` and `setLeftTop` in existing way actually works only for view with absolute positioning, so it is super rare and special case;
* Internally, setting `frame` only make sense to `RootView`, and in that case there we always must not change `origin` we are introducing `setSize` method.
Changes:
* `[-RCTShadowView setFrame:]` was removed, `frame` property is readonly now;
* `[-RCTShadowView setLeftTop:]` was removed; no replacement provided;
* `[-RCTShadowView size]` read-write property was added;
* `[-RCTUIManager setFrame:forView:]` was deprecated, use (just introduced) `setSize:forView:` instead;
* `[-RCTUIManager setSize:forView:]` was added.
If you are still need some of removed methods, you are probably doing something wrong. Consider using `setIntrinsicContentSize`-family methods,
`setSize`-family methods, or (in the worst case) accessing `yogaNode` directly.
Reviewed By: javache
Differential Revision: D4491384
fbshipit-source-id: 56dd84567324c5a86e4c870a41c38322dc1224d2
Summary:
In theory, we should be able to animate any non-layout property, including custom ones. While there is still work to be done on the native side to fully enable this, we should start by dropping the prop whitelist.
Closes https://github.com/facebook/react-native/pull/10658
Differential Revision: D4379031
Pulled By: ericvicenti
fbshipit-source-id: fe9c30ea101e93a8b260d7d09a909fafbb82fee6
Summary:
Following the PR https://github.com/facebook/react-native/pull/6195, this adds a `HEIGHT` constant on `StatusBar` for iOS.
Combined with `statusBarFrameDidChange` and `statusBarFrameWillChange` StatusBar native events, it solves various problems with In-Call cellar bar / Location bar / others 40pt status bars, and offers a correct `keyboardVerticalOffset` value for the KeyboardAvoidingView component.
Closes https://github.com/facebook/react-native/pull/12041
Differential Revision: D4450924
Pulled By: hramos
fbshipit-source-id: 664798260f4226140f3fa3f9222a415a305d0d78
Summary:
Add one more parameter which can specify the keyboard type of first text input(if exists) to AlertIOS.prompt().
Example usage:
`AlertIOS.prompt('Type a phone number', null, null, 'plain-text', undefined, 'phone-pad')`
Closes https://github.com/facebook/react-native/pull/8781
Differential Revision: D4437900
Pulled By: hramos
fbshipit-source-id: 8141cc0d7c70d13603cd5a1d5ea3f1ab1ce437a6
Summary: Switch to using IS_TESTING on the Platform module. While IS_TESTING has to be explicitly set in the test harness, this makes it more usable and stops people from relying on brittle variables in the (larger) environment.
Reviewed By: fkgozali
Differential Revision: D4423661
fbshipit-source-id: 27a80867778b9374bcba67b69f9c93d32c0a74b0
Summary:
Right now from JS there's no way to see the environment variables or arguments that the application was started with.
The main use case for this is to help enable/disable features when being run in a testing environment (as environment variables are the easiest way to communicate).
javache is it okay to reference these constants from JS at startup time? I am planning to disable yellow boxes via an environment variable.
achen1 how easy is it expose these two things for Android as well?
Reviewed By: achen1
Differential Revision: D4395091
fbshipit-source-id: fc318e6a60b8829f7eb4491ea8f3258f68f59c8c
Summary:
Fixes the build warning:
```react-native/React/Modules/RCTRedBox.m:406:58: Conversion from value of type 'NSArray<RCTJSStackFrame *> *' to incompatible type 'NSArray<NSDictionary *> *```
This appears because the compiler is left to infer the type of `stack`, and it does so as `NSArray<RCTJSStackFrame *>` based on [RCTRedBox.m#L390](https://github.com/facebook/react-native/blob/master/React/Modules/RCTRedBox.m#L390). In reality `stack` may be either of two types and the function body deals with normalisation.
Mark the stack as explicitly `NSArray<id>` to prevent inference so we're free to make the decision to cast to more specific types.
Closes https://github.com/facebook/react-native/pull/11807
Differential Revision: D4402916
fbshipit-source-id: 356343f244af7638b9b9e91c2c5b7e68de0cbd33
Summary:
Motivation: reduce build noise that might worry new users or hide real problems.
This deals with four of the warnings currently in the iOS build. The `__unused` additions are standard and self-explanatory, following the style used elsewhere in RN. I've used `#pragma unused` to deal with parameters named by macros.
Tested by building and running the `UIExplorer` example app in XCode 8.2
Closes https://github.com/facebook/react-native/pull/11797
Differential Revision: D4396611
fbshipit-source-id: 728e9ebb94d147f7a2cbc674a25fe67e66e2e8b2
Summary:
On certain devices (in my case, any iPad Pro model), listening to `DeviceEventEmitter.didUpdateDimensions` would call back *before* the interface change takes places (i.e. calling `Dimensions.get()` in this callback would return wrong values). Turns out that we were listening for the wrong native event.
Edit to add: now using `[RCTSharedApplication() statusBarOrientation]` to get the current orientation. Not yet sure why, but the `userInfo` provided by the notification was returning the wrong orientation *only* on the first time you rotate the device.
This fixes the open issue: https://github.com/facebook/react-native/issues/7340
Closes https://github.com/facebook/react-native/pull/11350
Differential Revision: D4348186
Pulled By: javache
fbshipit-source-id: cb2cfb9cccfc459ad4b46a5af2bec4c973132ae8
Summary: No need to have two files; merge it into one and give it an appropriate name.
Reviewed By: javache
Differential Revision: D4296716
fbshipit-source-id: 904d13c23bb8d403b8efcb60f9a4aa5df5b08972
Summary: This singleton was unnecessary and can be implemented with a single `static` in `RCTDevMenu`. In another diff, I will rename `RCTWebSocketManager.{h,m}` to reflect the only class that remains.
Reviewed By: javache
Differential Revision: D4296551
fbshipit-source-id: 653971dfb31de5b0a161b531eed82a067f536ce3
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary:
Corresponding Android PR: https://github.com/facebook/react-native/pull/11008
This gives apps the ability to find out the current scaling factor for fonts on the device. An event was also added so that apps can find out when this value changes.
**Test plan (required)**
Verified that the getter and the event work properly in a test app. Also, this change is used in my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11010
Differential Revision: D4207620
Pulled By: ericvicenti
fbshipit-source-id: b3f6f4a412557ba97e1f5fb63446c7ff9a2ff753
Summary:
The various RCTLog macros (`RCTLogWarn`, `RCTLogError`, etc..) are based on the `_RCTLog` macro, which, in its expanded form, has a semi-colon in DEV mode (i.e., when `RCTLOG_ENABLED` is set to 1), and doesn't have one when `RCTLOG_ENABLED` is set to 0.
This could lead to a situation where code will compile in DEV but will fail to compile for prod.
Fixing this by removing the semicolon from the DEV version (as should).
Reviewed By: javache
Differential Revision: D4189133
fbshipit-source-id: 54cb4e2c96d1e48d9df88464aa58b13af432c2bd
Summary:
1. Using weak container to hold the currently opened alerts.
2. Using weak reference to alertController in action handler block.
3. BTW, remove the unused vars: _alertCallbacks, _alertButtonKeys.
Test plan (required)
```
- (void)invalidate
{
for (UIAlertController *alertController in _alertControllers) {
[alertController.presentingViewController dismissViewControllerAnimated:YES completion:nil];
}
}
```
Since we use weak container, _alertControllers should only contains the currently opened alerts.
I test this way: Put a breakpoint in invalidate, open the UIExplorer play with the 'Alert' & 'AlertIOS' examples, then fire a reload and see if _alertControllers contains the expected values.
Closes https://github.com/facebook/react-native/pull/10407
Differential Revision: D4078649
Pulled By: lacker
fbshipit-source-id: 8509e7e7142379a81d5b28c9067c085bad8bb5cb
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
This fixes the following problem on iPad (happens when trying to show the devmenu ActionSheet):
> Terminating app due to uncaught exception 'NSGenericException', reason: 'Your application has presented a UIAlertController () of style UIAlertControllerStyleActionSheet. The modalPresentationStyle of a UIAlertController with this style is UIModalPresentationPopover. You must provide location information for this popover through the alert controller's popoverPresentationController. You must provide either a sourceView and sourceRect or a barButtonItem. If this information is not known when you present the alert controller, you may provide it in the UIPopoverPresentationControllerDelegate method -prepareForPopoverPresentation.'
I see 2 ways of fixing the issue: falling back to Alert (always displayed in the center) or adding a fake view somewhere on the screen to display the ActionSheet.
Reviewed By: mmmulani
Differential Revision: D3989672
fbshipit-source-id: 59fabc50ec1aac3ae6ddd7ecf4d8e8e5b9586dba
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
- Being able to call these from JS is really useful in envs where action sheets are not available (eg: App Extensions). I made the functions act as explicit toggles, this way it's easy to set the wanted behavior.
**Test plan (required)**
- I tested the functions manually.
Closes https://github.com/facebook/react-native/pull/9242
Differential Revision: D3749568
fbshipit-source-id: 2cea1d609dc792aec73d4bcf1eae07575725b4b7
Summary:
At the moment, posting RCTReloadNotification in any circumstance causes all RCTBridge instances to reload. This change scopes the notification to the bridge for which it was intended.
Closes https://github.com/facebook/react-native/pull/8762
Differential Revision: D3831914
fbshipit-source-id: ff29574f574ecd1a403057ddd0458dea38f0136e
Summary:
Include CSSLayout headers in the same way as other project headers, ie `#import <CSSLayout/CSSLayout.h>` becomes `#import "CSSLayout.h"`. CSSLayout is not a framework or system dependency, so shouldn't (AFAIK) be included with angle brackets. Doing so breaks framework builds, such as when RN is used as a pod in a swift project.
In combination with https://github.com/facebook/css-layout/pull/217 this fixes https://github.com/facebook/react-native/issues/9014 (specifically swift cocoapods projects). There is then no need for a separate CSSLayout pod subspec.
Tests run on the RN project in isolation (with changes inside `CSSLayout` itself also applied) and against a dummy swift project with RN included as a pod.
NB: This effectively reverts https://github.com/facebook/react-native/pull/9015 and may break non-swift cocoapods projects unless https://github.com/facebook/css-layout/pull/217 is merged and synced first.
Update: As discussed with alloy and emilsjolander, wrap these imports in a preprocess
Closes https://github.com/facebook/react-native/pull/9544
Differential Revision: D3821791
Pulled By: javache
fbshipit-source-id: d27ac8be9ce560d03479b43d3db740cd196c24da
Summary: added API to in UIManager to find the rootTag/View of any reactTag based on its layout (shadow views) hierarchy (not to be used by JS)
Reviewed By: javache
Differential Revision: D3750410
fbshipit-source-id: 68611e39930d53ece478f25245ddc7f7838daaa6
Summary:
1. Provide forceRTL function for developer to test RTL layout in LTR language bundle in I18nUtil and expose it in I18nManager.
2. Rename `allowRTL` and `setAllowRTL` functions
Reviewed By: fkgozali
Differential Revision: D3663693
fbshipit-source-id: 3db13a44c069ae73d1728c211306422db5dd8122
Summary:
When call `[RCTDevMenu invalidate]`, it will cancel updateTask. But in fact, after the `[updateTask cancel]`, the updateTask's completionHandler will call `checkForUpdates` again, so it will create a new updateTask.
Closes https://github.com/facebook/react-native/pull/6165
Differential Revision: D3669576
Pulled By: javache
fbshipit-source-id: 443924b7f4be1716797fc5690e90d962cf31b923
Pieter De Baets
Adam Comella
Valentin Shergin
William Schurman
Connor McEwen
Emily Janzer
Marc Horowitz
Alex Dvornikov
Ben Roth
Shruti Malugu
Janic Duplessis
Pieter De Baets
Daniele Conti
Jhen
Ashwin Bharambe
Kevin Gozali
Eloy Durán
Lukas Piatkowski
Mathieu Baudet
Ryan Gomba
Mathieu Acthernoene
yueshuaijie
Mehdi Mulani
Rob Hogan
Dan Caspi
rh389
Mani Ghasemlou
Adam Ernst
Emil Sjolander
Vojta Bartos
rcaferati
Grace Ku
littlesome
dlowder-salesforce
Alex Kotliarskyi
Alexander Pantyuhov
Hugo Dozois
makee
Scott Wolchok
Mengjue Wang
wenzhao.yin
Brent Vatne
