Summary:
Changelog: [Internal]
Previously `setTextAndSelection` was not dirtying layout. This would cause an issue where `setTextAndSelection` causes layout change. For example calling setTextAndSelection with empty string on a multiline auto expanding text input.
I changed one example in TextInputSharedExamples.js, "Live Re-Write (no spaces allowed) and clear" example is now multiline. This allows to test whether `setTextAndSelection` dirties layout. Enter multiline string to to the example text input and press clear. Observe that the text input shrinks to single line height.
Reviewed By: shergin
Differential Revision: D21182990
fbshipit-source-id: de8501ea0b97012cf4cdf8d5f658649139f92da6
Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested to solve the problem not on the level of RCTTextAttributes, but on the level of RCTUITextField.
Setting `self.textColor = [UIColor black];` in the constructor did not work, because it gets overwritten by nil in `RCTBaseTextInputView.m`. There I implemented the logic that if NSForegroundColorAttributeName color is nil then the color is being set to black. I think the `defaultTextAttributes` property confuses here, because it ends up being the effective text attributes, e.g. if I unconditionally set the default text color to black, it cannot be changed in React Native anymore. So I put the nil check in.
## Changelog
[iOS] [Fixed] - TextInput color has the same default (#000) on iOS whether in light or dark mode
Pull Request resolved: https://github.com/facebook/react-native/pull/28708
Test Plan:
I have manually tested the following:
- The default text color in light mode is black
- The default text color in dark mode is black
- The color can be changed using the `style.color` attribute
- Setting the opacity to 0.5 results in the desired behavior, the whole TextInput becoming half the opacity.
– Setting the `style.color` to rgba(0, 0, 0, 0.5) works as intended, creating a half-opaque text color.
Differential Revision: D21186579
Pulled By: shergin
fbshipit-source-id: ea6405ac6a0243c96677335169b214a2bb9ccc29
Summary:
Changelog: [Internal]
We don't use view command `setMostRecentEventCount`, let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D21016600
fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
Changelog: [Internal]
# Fabric
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
2. In view commands, do not validate `eventCount`. It is passed in as undefined from JS because Fabric's text input doesn't use `eventCount`.
# Paper
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
Reviewed By: shergin
Differential Revision: D20538290
fbshipit-source-id: c7aeddc25f58697254474058ce901df958321f7c
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
Resolve React-RCTText warning: `'UIKeyboardTypeASCIICapableNumberPad' is only available on iOS 10.0 or newer`
## Changelog
[iOS] [Fixed] - Resolve React-RCTText Xcode warning
Pull Request resolved: https://github.com/facebook/react-native/pull/28054
Test Plan: Build template, React-RCTText should no longer throw a warning.
Differential Revision: D19887063
Pulled By: hramos
fbshipit-source-id: 3437ee993babd7cdaec259af24526e197acb64bb
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary:
Fixes https://github.com/facebook/react-native/issues/27137
This PR fixes an issue on iOS where RCTTextView height is not calculated as it should for some fonts where font `leading` attributed is not equal to zero, which results in wrong baseline alignment behaviour.
The fix for this is by setting `usesFontLeading` property of `NSLayoutManager` to `NO`, which results is a layout behavior that is similar to `UILabel`
Probably the documentation for `usesFontLeading` describes why UILabel has a different (correct) layout behavior in that case
> // By default, a layout manager will use leading as specified by the font. However, this is not appropriate for most UI text, for which a fixed leading is usually specified by UI layout guidelines. These methods allow the use of the font's leading to be turned off.
## Changelog
[iOS] [Fixed] - Fix RCTTextView layout issue that happens on some font with `leading` attribute not equal to zero, which causes wrong base-alignment layout
Pull Request resolved: https://github.com/facebook/react-native/pull/27195
Test Plan:
Below are the test results before and after the change, and comparing that to native UILabel behavior.
The test is done with using system font and custom font (`GothamNarrow-Medium`) and font size 50
[GothamNarrow-Medium.otf.zip](https://github.com/facebook/react-native/files/3832143/GothamNarrow-Medium.otf.zip)
```js
const App: () => React$Node = () => {
return (
<View style={{flex: 1, margin: 40, flexDirection: 'row', justifyContent: 'center', alignItems: 'baseline'}}>
<View style={{width: 30, height: 30, backgroundColor: 'lightgray'}} />
<Text style={{fontSize: 50, backgroundColor: 'green', fontFamily: 'GothamNarrow-Medium'}}>{'Settings'}</Text>
</View>
);
};
```
-------
### Before the fix
<img width="962" alt="Screenshot 2019-11-11 at 16 53 26" src="https://user-images.githubusercontent.com/5355138/68601049-dd778780-04a3-11ea-879e-cc7b4eb2af95.png">
-----
### After the fix
<img width="944" alt="Screenshot 2019-11-11 at 16 55 11" src="https://user-images.githubusercontent.com/5355138/68601180-1d3e6f00-04a4-11ea-87bc-61c6fa2cdb18.png">
-----
### Using `UILabel`
<img width="805" alt="Screenshot 2019-11-11 at 16 59 28" src="https://user-images.githubusercontent.com/5355138/68601487-b2d9fe80-04a4-11ea-9a0f-c025c7753c24.png">
Differential Revision: D19576556
Pulled By: shergin
fbshipit-source-id: 4eaafdab963c3f53c461884c581e205e6426718a
Summary:
Add Native Commands handlers to TextInput.
It is intentionally done in a way so that it can be easily swapped for codegened implementation once we properly type TextInput.
We also add native commands to view managers for backwards compatibility.
Changelog: [Internal]
Reviewed By: TheSavior, shergin
Differential Revision: D19412026
fbshipit-source-id: 8dc64275cf1da599b1bd5992a41035d51dd4148f
Summary:
Re-landing the reverted change:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: sammy-SC
Differential Revision: D19411136
fbshipit-source-id: ec0a957dc57819f0ee7d138c858209cabe3e5102
Summary:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: hramos
Differential Revision: D19271321
fbshipit-source-id: 424ad7e2161261d148cb436cc20b4c531a4ba5b7
Summary:
RCTTextInputUtils contains a bunch of conventions and convenience functions that we use in TextInput.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19226658
fbshipit-source-id: df72dcdc052b96b6daef2cc0839235761005d914
Summary:
It is time to target SDK version 10.0+.
Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required
Reviewed By: mdvacca
Differential Revision: D19265731
fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
Summary:
`selectAll:` does not work for UITextView when it's being called inside UITextView's delegate methods.
This is a bug in UIKit and this quite ugly workaround is only a known solution for it.
Changelog: [Bug][iOS] Fixed bug in implementation of <TextInput>'s selectOnFocus prop
Reviewed By: sammy-SC
Differential Revision: D18966755
fbshipit-source-id: 2ba15fa94570d463a2ea3490331fb879611dc6b8
Summary:
Remove textColor font and textAlignment in RCTBackedTextInputViewProtocol since they're all wired up in defaultTextAttributes already
Changelog: [iOS] [Removed] Remove three properties: "textColor" "font" "textAlignment" from RCTBackedTextInputViewProtocol, unifying the usage into "defaultTextAttributes".
Reviewed By: PeteTheHeat
Differential Revision: D18954292
fbshipit-source-id: 17fd38a824d035843ae59b1b875dd9c48b3fcc9b
Summary:
We can use the HostComponent type now instead of NativeComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18871289
fbshipit-source-id: 3c70369c5848dedfc22ca6f6ccbb69d6d60a1330
Summary:
RCTBackedTextInputViewProtocol is a protocol that describes which capabilities must be exposed for some TextInput-like UIView to be compatible with the rest of TextInput infra. We use that in both implementations. In Classic React Native we use Objective-C runtime mechanisms to call many of those methods (via ViewManager's directives); that masked the problem that the protocol was incomplete.
In Fabric, we call all methods normally, so we need to declare all of them here.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950432
fbshipit-source-id: 3cd5cb57a033f7c43fd5f2c10f9706408e8e6d0c
Summary:
Both RCTUITextField and RCTUITextView must maintain the same public interface that describes all possible features that TextInput needs. That features are declared via `RCTBackedTextInputViewProtocol`.
`scrollEnabled` is a part of this protocol. The idea behind this prop was borrowed from `UIScrollView` class (which `UITextView` extends) and implemented for `RCTUITextField` (yeah, implemented as no-op).
In this diff we change the implementation of this prop to be more consistent with original implementation in UIScrollView:
* Now the name of the getter is now `isScrollEnabled`;
* The object now retains the actual value of the prop (even if it ignores that).
We need all those features for Fabric-compatible implementation.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950426
fbshipit-source-id: 50c399d0fbba1be31750dbe4f235a075f86e8c01
Summary:
We need to expose the `multiline` prop in View Manager class to enable Fabric component to use it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950429
fbshipit-source-id: 69b225b24b4512a1ea21381daacbf868a23ccf6d
Summary:
The general rule that we follow in RN is that the *exported* .h files must have only `<>` includes. That allows to use them outside of the library where they are defined. Those files are already exported technically, but without this change cannot be used as exported.
New Fabric text input implementation uses them, so we need to change those includes to have `<>` style.
Changelog: [Internal] Specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950427
fbshipit-source-id: 96cbe4cac9e28761c123bde8ac70464a0078ee6c
Summary:
This is a more feature-full replacement for `textInputShouldChangeTextInRange:replacementText:` that allows implementing things like limiting text input content length without hacks and compromising the order of events. The new version of the TextInput will rely on that. The existing TextInput will use that as exacly like the previous version (because the new API is a superset of the the old one).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18670792
fbshipit-source-id: 0c434b351dfc8ab42404eb9aea0ede70bedaa9dc
Summary:
The class `RCTUITextView` is designed to be a home for workarounds. In Fabric we will use it as well, so we need to have all workarounds there.
That's just a move of some code between clases, it does not really affect how the workarounds work.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18607833
fbshipit-source-id: 1ba0e8c5cd928f3bf6fe1d2727325ecfc1dbf684
Summary:
The moved code fragment is a workaround for a bug in UITextField in iOS 8. There is no need to have this code in a general base class that serves both UITextField- and UITextView-based components. Especially for such workarounds like that, we have a dedicated class RCTUITextField. This diff moves that there.
Read more about the bug:
https://stackoverflow.com/questions/14220187/uitextfield-has-trailing-whitespace-after-securetextentry-toggle/22537788#22537788
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18444734
fbshipit-source-id: a3764c19f562231ba3fa3d4c0ad7de069ea04d98
Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
Summary:
This fixes a bug reported by Oculus and OSS.
https://github.com/facebook/react-native/issues/26577
When rendering images nested in a `<Text/>` node, on the native side, `RCTTextShadowView` adds an empty NSTextAttachment to the attributed string to add some extra space. The image is then overlaid in the empty space . This all works fine and dandy on iOS12 and below.
Starting in iOS13, an empty NSTextAttachment doesn't render as blank space. It renders as the "missing image" white page. When the real image is overlaid on the white page, it looks super broken. See github issue and test plan for examples.
This fix is to assign an empty image to `NSTextAttachment`. I tried seeing if there was any other attribute we could use to just add white space to an attributed string, but this seems like the best one.
Changelog: [iOS][Fixed] Fixed bug rendering nested text on iOS13
Reviewed By: xyin96
Differential Revision: D18048277
fbshipit-source-id: 711cee96934fc1937d694621a4417c152dde3a31
Summary:
This diff changes how we apply default text attributes to backed text input.
The original change in https://github.com/facebook/react-native/pull/23585 that introduced the `reactTextAttributes` field in for RCTBackedTextInputViewProtocol was great! Thank you Wu zhongwuzw !
However, there is one detail that needs to be changed.
RCTBackedTextInputViewProtocol is designed to only abstract complexity of iOS text input components (UITextView and UITextField); it intentionally does not have any React-specific fields or types. Adding a field `RCTTextAttributes *reactTextAttributes;` violates this principle and make it hard to reuse this functionality in the new Fabric-powered TextInput.
This diff changes the type of this prop from `RCTTextAttributes` to `NSDictionary<NSAttributedStringKey,id> *` (exact same type that UITextView and UITextField use).
Reviewed By: cpojer
Differential Revision: D17408501
fbshipit-source-id: 65f2bba119ccc30f22e87c28d0f8ea6f731cd365
Summary:
The new podspec includes all .h and .m files, `RCTInputAccessoryViewContent` was missing a tvOS guard.
## Changelog
[iOS] [Fixed] - Restore RCTText tvOS pod compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/26332
Test Plan: Build RCTText for tvOS
Differential Revision: D17258958
Pulled By: cpojer
fbshipit-source-id: 5e7408680133aa3ec111552d1413a928193945a7
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary:
Move RCTAccessibilityManager to CoreModules (since that's the only dir that supports TM).
Fixup some variable names to match spec.
Reviewed By: RSNara
Differential Revision: D16861739
fbshipit-source-id: a0a53b221dcc172979d1f2c83851ab92e23f2333
Summary:
This pull request moves `Text`'s prop types to the `DeprecatedPropTypes` folder.
This was already partly in progress - there were redundant `TextPropTypes` and `DeprecatedTextPropTypes` files so I removed one, and made sure the version with the doc strings was the one used.
## Changelog
[General] [Deprecated] - Move `Text` component's proptypes to DeprecatedPropTypes
Pull Request resolved: https://github.com/facebook/react-native/pull/26055
Test Plan: Flow checks pass for iOS and Android
Differential Revision: D16801078
Pulled By: TheSavior
fbshipit-source-id: ef19300945d48d0a4a83d728ee32cdf7d1c0f0cc
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by 33573511f0.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary:
Original commit changeset: c45409a8413e
I was unable to find the cause of the problem.
Reviewed By: yungsters
Differential Revision: D16240754
fbshipit-source-id: c1e3f0aa615422f1156706f919e8f851f82c18b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25583
We now use CocoaPods for better maintainability.
Reviewed By: hramos
Differential Revision: D16193719
fbshipit-source-id: 26382f2da4eaba14a71771540b587fdc80b41108
Summary:
This PR adds initial support for Project Catalyst a.k.a. UIKitForMac. This is not yet meant for production, but this is enough for RNTester to successfully compile and mostly work :)
Some APIs are not supported on the Mac -- e.g. telephony, and deprecated APIs are removed on Mac ���-- those had to be ifdef'd out via platform checks.
The biggest limitation right now is that I couldn't get Web Socket code to successfully compile, and so there are a lot of temporary platform checks for that , and the RCTWebSocket.xcodeproj is marked as not supporting UIKitForMac. Again -- temporary, until someone with more knowledge knows how to fix this.
https://github.com/react-native-community/discussions-and-proposals/issues/131
## Changelog
[iOS] [Added] - Fixed compilation for macOS (Project Catalyst) -- not meant for production use yet
Pull Request resolved: https://github.com/facebook/react-native/pull/25427
Test Plan:
- Open RNTester/RNTester.xcodeproj with Xcode 10.2, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
- Open the same project with Xcode 11 beta 2 (or higher) on macOS Catalina beta, select "My Mac" as device target, and run -- see that it actually compiles and runs. **Note** there are unfortunately some required steps:
- change build configuration to Release (because packager doesn't work correctly yet)
- change development team to yours if Xcode tells you to
- go to RNTester project → Build phases → Link binary with libraries, and change `platforms` for `libRCTWebSocket.a` to `iOS` (without Mac compatibility). I can't commit that change because it breaks compatibility with earlier Xcode versions
The two extra steps for successful compile will disappear once web socket compilation for Catalyst is fixed
Reviewed By: mmmulani
Differential Revision: D16088263
Pulled By: sammy-SC
fbshipit-source-id: 9c0b932b048e50a8e0f336eaa0612851b1909cae
Summary:
On `textContentType` `newPassword` on ios, there is another property called `passwordRules` on ios 12 that can give hints to the os to generate a password with specific requirements like [here](https://developer.apple.com/password-rules/).
This is useful for apps that have a "register" screen with `emailAddress`/`username` and a `newPassword` fields, to let ios make a password that will satisfy the requirements and not one that might be not accepted after the user presses "register".
## Changelog
[iOS] [Added] - PasswordRules for new password textContentType input fields
Pull Request resolved: https://github.com/facebook/react-native/pull/25407
Test Plan: This is a bit harder, but to test you need to make an app that has associated domains with an apple-app-site-association file on that domain, enable iCloud Keychain on the test device, and then iOS will suggest a password, otherwise you will just get a warning on Xcode saying "Couldn't suggest password because of: blabla".
Differential Revision: D16028684
Pulled By: cpojer
fbshipit-source-id: d22426e07f1db45d1f79f5dad81f1465a9701f0b
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
This is similar to https://github.com/facebook/react-native/pull/24995 but for iOS.
Motivation: when building a custom Text or TextInput (eg with rich text support), one needs custom text processing logic (turning the JS text value to a `NSAttributedString`).
RCTBaseTextShadowView contains `- (NSAttributedString *)attributedTextWithBaseTextAttributes:(nullable RCTTextAttributes *)baseTextAttributes;`
853c667eb5/Libraries/Text/BaseText/RCTBaseTextShadowView.m (L78)
This method, given `self.reactSubviews` creates and returns an instance of [NSMutableAttributedString](https://developer.apple.com/documentation/foundation/nsmutableattributedstring?language=objc). It's currently possible to override this method in subclasses, but the original implementation reads and writes two cache fields which are private. This PR just changes the access modifiers so that subclasses of `RCTBaseTextShadowView` can also access the caching fields.
## Changelog
Not needed I guess.
Pull Request resolved: https://github.com/facebook/react-native/pull/25283
Test Plan: This will work just the same - works locally, CI should pass.
Differential Revision: D15873741
Pulled By: cpojer
fbshipit-source-id: dd26a4241f2ac6c0870b6c302939e2f3b0ecc8ff
Samuel Susla
Jonny Burger
Michael Bolin
Tom Underhill
Rachel Nabors
Jason Safaiyeh
Janic Duplessis
Ahmed Ibrahim
Kevin Gozali
Jiawei Lv
Valentin Shergin
Jimmy Zhang
Eli White
Peter Argany
Andres Suarez
Benoit Dion
Marc Mulcahy
glevi@fb.com
empyrical
Logan Daniels
James Treanor
Min ho Kim
Radosław Pietruszewski
Pavlos Vinieratos
Christoph Nakazawa
Vojtech Novak
