Summary:
This is reimagining of interoperability layer between Yoga and ShadowViews (at least in Yoga -> RN part).
Goals:
* Make it clear and easy.
* Make clear separation between "what layout what", now parent always layout children, noone layout itself.
* Make possible to interleave Yoga layout with custom imperative layout (may be used in SafeAreaView, Text, Modal, InputAccessoryView and so on).
Reviewed By: mmmulani
Differential Revision: D6863654
fbshipit-source-id: 5a6a933874f121d46f744aab99a31ae42ddd4a1b
Summary:
The problem was recently introduced in the last refactoring of the Text module.
There are two problem actually:
(1) Compare this current code with stable version.
In the stable version the event is only triggered here:
https://github.com/facebook/react-native/blob/0.52-stable/Libraries/Text/RCTTextField.m#L132-L140
In the new version the event is triggered in two places (which is obviously wrong).
(2) Executing `[_eventDispatcher sendTextEventWithType:RCTTextEventTypeChange:...]` and _onChange() actually do the same thing.
Historically, the single-line <TextInput> used the first approach and multi-line used second one. When we unify the logic, mixed both of them, which was apparenly wrong.
So, we have to remove another call of `[_eventDispatcher sendTextEventWithType:RCTTextEventTypeChange:...]`.
The the future we have to completly remove usage of `_eventDispatcher` from this component.
Depends on D6854770.
Reviewed By: fkgozali
Differential Revision: D6869678
fbshipit-source-id: 6705ee8dda2681ae184ef6716238cc8b62efeff1
Summary:
Even if we don't support this prop yet, we have to expose this in RCTUITextView to conform the contract between ViewManager and ShadowView.
Same story as D6842304.
Depends on D6842304.
Reviewed By: fmoo
Differential Revision: D6869750
fbshipit-source-id: 9b35f1a38040319ec66f1ec12f97ac739f8b204f
Summary:
Without this change native RCTVirtualText module is unactive on iOS.
This can cause bags in Text rendering because failback module (RCTVirtualText) does not popagate dirty status upward.
Depends on D6842304.
Reviewed By: yungsters, AaaChiuuu
Differential Revision: D6854770
fbshipit-source-id: ab8b7acd67309b7351c0074293ee6515a55385ce
Summary: Even if we don't support this prop yet, we have to expose this in RCTUITextView to conform the contract between ViewManager and ShadowView.
Reviewed By: sahrens
Differential Revision: D6842304
fbshipit-source-id: 7ea26974f595eba6a3c06df06ca01e46af2e63df
Summary: `contentFrame` is now always provided by shadow thread (with attributed string and embedded views), so we have to update it on every single relayout.
Reviewed By: yungsters
Differential Revision: D6817401
fbshipit-source-id: c2a1f314f34a2187053eb11ce0744c935edbb8ae
Summary:
Now, in the new model, we transfer text attributes with actual text via attributed text to a native text component,
so previous text-only comparsion is not sufficient anymore.
Depends on D6600685.
Differential Revision: D6809833
fbshipit-source-id: 475b7426cf3c6694781790d99ef32466606da2f2
Summary:
This is a complete rewrite of RCTText, the part of React Native which manages Text and TextInput components.
Key points:
* It's understandable now. It follows a simple architectural pattern, and it's easy to debug and iterate. Text flow layout is a first-class citizen in React Native layout system now, not just a wired special case. It also brings entirely new possibilities such as nested interleaving <Text> and <View> components.
* All <Text>-specific APIs were removed from UIManager and co (it's about ~16 public methods which were used exclusively only by <Text>).
* It relies on new Yoga measurement/cloning API and on-dirty handler. So, it removes built-in dirty propagation subsystem from RN completely.
* It caches string fragments properly and granularly on a per-node basis which makes updating text-containing components more performant.
* It does not instantiate UIView for virtual components which reduces memory utilization.
* It drastically improves <TextInput> capabilities (e.g. rich text inside single line <TextInput> is now supported).
Screenshots:
https://cl.ly/2j3r1V0L0324https://cl.ly/3N2V3C3d3q3R
Reviewed By: mmmulani
Differential Revision: D6617326
fbshipit-source-id: 35d4d81b35c9870e9557d0211c0e934e6072a41e
Summary:
Currently `isInAParentText` context works as imaginary `isInAAncestorText` context (not like a real `isInAParentText`).
Let's imagine we have hierarchy like:
`View -> Text -> Text* -> View* -> Text* -> Text* -> View*`
With current implementation all nodes marked with asterisk have `isInAParentText` context, which is incorrect (because some of them actually in View context).
With the new implemetations it will work like this:
`View -> Text -> Text* -> View* -> Text -> Text* -> View*`
So, only nodes which have <Text> (or <TextInput>) as a parent will have `isInAParentText` context.
This change allows to select proper `Text` vs. `VirtualText` component in cases where <Text> and <View> components can interleave each other.
Reviewed By: sahrens
Differential Revision: D6690495
fbshipit-source-id: f7c59b23d0eaf68a1d08036b858d99c9547f7878
Summary:
iOS TV CI is currently broken.
CI for both iOS and iOS TV successfully pass.
[INTERNAL] Continous integration for iOS fixed.
Closes https://github.com/facebook/react-native/pull/17564
Differential Revision: D6711693
Pulled By: hramos
fbshipit-source-id: c36ffc2581dac69cb6e4f8670f21c2816496e9df
Summary: Bunch or identical code was moved to superclass.
Reviewed By: mmmulani
Differential Revision: D6663772
fbshipit-source-id: 82321f56bbab0e9d17c0227c97dd86904cf5ab30
Summary:
The previous file/class name convention seemed cool... but now it drives me BANANAS! It makes all this code really hard to maintain.
So, evething were renamed following common modern RN convention.
Reviewed By: mmmulani
Differential Revision: D6605090
fbshipit-source-id: 88ca13d793a5d2adaac2b7922ec6bd4654aacec5
Summary: As it was mentioned in previous diffs, we are removing this because it overcomplicates rendering layer and provides (almost) no benefits (and cannot be implemented 100% accurate way).
Reviewed By: mmmulani
Differential Revision: D6582560
fbshipit-source-id: 0778db96a45dd8e2520268d5d00792677cb01a20
Summary:
This is a long story. Awhile ago awesome Nick Lockwood (Hey Nick!) introduced a special optimization for ReactNative rendering layer called "inherited background color".
He described this idea in D2811031:
>>>
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just <Image/> and <Text/> components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except <Text/> nodes. It might still be useful for <Image/> nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
However. I think it is time to remove it. Why? There are several reasons:
* It drastically complicates rendering layer. DRASTICALLY. In many many unrelated places (try search for "backgroundColor"!);
* This mechanism is totally non-conceptual to RN and it prevents us to implement some new possible render optimization that we plan to do;
* This adopted only by two components now: Text and ART;
* This is not a significant performance drain anymore; from iOS 6 even UILabel has clear background color by default.
* I doubt that it even works now because `drawRect:` in Text component does not call super method.
So, this diff just turns this feature off for Text. If all performance metrics are neutral, I will delete this mechanism.
Peace.
Reviewed By: sahrens
Differential Revision: D6564199
fbshipit-source-id: 70524fdd955ca32bbf86d2d1ff5e73316b791219
Summary:
Found this minor issue while reading the docs.
n/a
[DOCS] [BUGFIX] [Libraries/Text/Text.js] - Add return to example
Closes https://github.com/facebook/react-native/pull/16752
Differential Revision: D6274215
Pulled By: hramos
fbshipit-source-id: ef735eb9179ab69d2ed1bc4a8b5e921d42d88fb0
Summary:
The relevant changes in the PR are to Libraries/StyleSheet/EdgeInsetsPropType.js; the rest are just removals of FlowIgnores.
The definition of the relevant types is [here](https://github.com/facebook/flow/blob/master/lib/react.js#L262-L271).
The long and short of it is that for whatever reason, Flow is unable to realize that `ReactPropsChainableTypeChecker` is a subtype of `ReactPropsCheckType` unless we assert it. Once we explicitly hint this to the typechecker, it realizes that `EdgeInsetsPropType` is indeed a valid React PropType, and stops complaining that it isn't.
Closes https://github.com/facebook/react-native/pull/16437
Differential Revision: D6109742
Pulled By: sahrens
fbshipit-source-id: e4e10720b68c912d0372d810409f389b65d7f4b1
Summary:
Now RCTTextInput relies on ivar to detect should it reconstruct inputAccessoryView or not.
Previously we checked `inputAccessoryView` directly which breaks some 3rd party libs.
See https://github.com/facebook/react-native/issues/16071 for more details.
cc douglasjunior
Reviewed By: javache
Differential Revision: D5994798
fbshipit-source-id: c086efdd24f5528393a4c734ff7c984e0ed740d1
Summary:
This is required for D5874536, wherein I'll be introducing direction-aware props for borders.
When a view's border changes due to a direction update, only the frames of its children update. Therefore, only the children `UIView`s get a chance to be re-rendered. This is incorrect because the view that's had its borders changed also needs to re-render. So, I keep a track of the layout direction in a property on all shadow views. Then, when I update that prop within `applyLayoutNode`, I push shadow views into the `viewsWithNewFrames` set.
Reviewed By: mmmulani
Differential Revision: D5944488
fbshipit-source-id: 3f23e9973f3555612920703cdb6cec38e6360d2d
Summary:
Currently, only `Text` supports the `allowFontScaling` prop. This commit adds support for it on `TextInput`.
As part of this change, the TextInput setters for font attributes (e.g. size, weight) had to be refactored. The problem with them is that they use RCTFont's helpers which create a new font based on an existing font. These helpers lose information. In particular, they lose the scaleMultiplier.
For example, suppose the font size is 12 and the device's font multiplier is set to 1.5. So we'd create a font with size 12 and scaleMultiplier 1.5 which is an effective size of 18 (which is the only thing stored in the font). Next, suppose the device's font multiplier changes to 1. So we'd use an RCTFont helper to create a new font based on the existing font but with a scaleMultiplier of 1. However, the font didn't store the font size (12) and scaleMultiplier (1.5) separately. It just knows the (effective) font size of 18. So RCTFont thinks the new font has a font size of 18 and a scaleMultiplier of 1 so its effective font size is 18. This is incorrect and it should have been 12.
To fix this, the font attributes are now all stored individually. Anytime one of them changes, updateFont is called which recreates the font from scratch. This happens to fix some bugs around fontStyle and fontWeight which were reported several times before: #13730, #12738, #2140, #8533.
Created a test app where I verified that `allowFontScaling` works properly for `TextInputs` for all values (`undefined`, `true`, `false`) for a variety of `TextInputs`:
- Singleline TextInput
- Singleline TextInput's placeholder
- Multiline TextInput
- Multiline TextInput's placeholder
- Multiline TextInput using children instead of `value`
Also, verified switching `fontSize`, `fontWeight`, `fontStyle` and `fontFamily` through a bunch of combinations works properly.
Lastly, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14030
Reviewed By: TheSavior
Differential Revision: D5899959
Pulled By: shergin
fbshipit-source-id: c8c8c4d4d670cd2a142286e79bfffef3b58cecd3
Summary:
The Android ViewManager already has disabled set to false by default. When setting it in defaultProps we send it over for every text view, which is unnecessary.
On platforms that don't support disabled this may also cause unnecessary log noise.
Closes https://github.com/facebook/react-native/pull/16139
Differential Revision: D5944334
Pulled By: javache
fbshipit-source-id: 54c4b65f345cd284759d01d075522f5aa2f74298
Summary: NaN values can not be compared directly, so we have to use `isnan` function.
Reviewed By: mmmulani
Differential Revision: D5859761
fbshipit-source-id: bf99a1ae574cd820265bef0c2bd255b194c5dc3c
Summary:
Looks like `-[NSLayoutManager ensureLayoutForTextContainer:textContainer]` has a bug that cause infinite loop inside this method
during measuring some special characters AND when specified `width` equals NaN (which is useless anyways).
So, we cover this case in this diff.
Reviewed By: javache
Differential Revision: D5859767
fbshipit-source-id: 58a5910f21f282bf5b82494916b5b02ad72d357f
Summary:
**PR changes**
The RCTText class originally overrode the accessibilityLabel and returned the raw text of the class ignoring if the accessibilityLabel was set explicitly in code.
Example:
<Text accessibilityLabel="Example"> Hello World </Text> // returns "Hello World" instead of "Example" for the accessibility label
My update checks if the super's accessibilityLabel is not nil and returns the value else it returns the raw text itself as a default to mirror what a UIKit's UILabel does. The super's accessibilityLabel is nil if the accessibilityLabel is not ever set in code. I don't check the length of the label because if the value was set to an empty purposely then it will respect that and return whatever was set in code.
With the new changes:
<Text accessibilityLabel="Example"> Hello World </Text> // returns "Example" for the accessibilityLabel
This change doesn't support nested <Text> components with both accessibilityLabel's value set respectively. The parent's value will return.
Example:
// returns "Example" instead of "Example Test" for the accessibility label
<Text accessibilityLabel="Example">
Hello
<Text accessibilityLabel="Test">
World
</Text>
</Text>
The workaround is just to set the only the parent view's accessibilityLabel with the label desired for it and all its nested views or just not nest the views if possible.
I believe a bigger change would be needed to support accessibility for nested views, for now the changes I have made should satisfy the requirements.
Reviewed By: shergin
Differential Revision: D5806097
fbshipit-source-id: aef2d7cec4657317fcd7dd557448905e4b767f1a
Summary:
When you have a numeric non-multiline `TextInput` and a `returnKeyType` is `done` we automatically add an input accessory view ([implementation](603cc48ceb/Libraries/Text/RCTTextInput.m (L269)#L315)).
That view has a done button which triggers [handleInputAccessoryDoneButton](603cc48ceb/Libraries/Text/RCTTextInput.m (L317...L320)) which currently directly sends `endEditing:` to the text field / text view. As a consequence, the [textInputShouldReturn](603cc48ceb/Libraries/Text/RCTTextInput.m (L118...L121)) is not called and we dismiss the keyboard even if the `blurOnSubmit` value is `false`.
Confirm that the keyboard is not dismissed when you tap on Done button on this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit={false}
/>
```
and that the keyboard is dismissed for this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit
/>
```
Closes https://github.com/facebook/react-native/pull/15438
Differential Revision: D5601462
Pulled By: javache
fbshipit-source-id: 24e4048e2e66d1a42fa97d83b4a3eb61e5d817ea
Summary:
Several changes here. The `Text.md` and `PixelRatio.md` files were appended to the autodocs during site generation. This seemed excessive for just two files, so I've just merged the content into the autodocs themselves. It should help us simplify the website generation process in the future.
I've also merged IssueGuidelines.md and PullRequestGuidelines.md into the Contribution/Maintainers guidelines to improve their visibility.
Finally, I renamed Help to Community in the nav bar.
Ran the website locally, and verified every page rendered as expected: the Community page, Contributing page, Maintainers page.
Closes https://github.com/facebook/react-native/pull/15374
Differential Revision: D5567400
Pulled By: hramos
fbshipit-source-id: e06056edb12c9a17319fe1af46b2ef3a2e1b5854
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary: Because of some rebase issue `reactAccessibilityElement` was implemented with old invalid name, which breaks some accessibility features.
Reviewed By: mmmulani
Differential Revision: D5458283
fbshipit-source-id: 1e66a2f54c1f1a85118c9432b68895679a10059c
Valentin Shergin
Spencer Ahrens
Héctor Ramos
Liubov Zvereva
Semen Zhydenko
Sergei Dryganets
Tim Yung
Pritesh Nandgaonkar
Douglas
Erik Behrends
Avik Chaudhuri
Mehdi Mulani
ashoat
Cameron Little
Ramanpreet Nara
Jason Carreiro
Adam Comella
Pieter De Baets
Jakub Grzmiel
Brian Vaughn
Joshua Alvarado
Marshall Roch
Caleb Meredith
Danil Gontovnik
Adlai Holler
Pieter De Baets