Summary:
If text is truncated and an inline view appears after the truncation point, the user should not see the inline view. Instead, we have a bug such that the inline view is always visible at the end of the visible text.
This commit fixes this by marking the inline view as hidden if it appears after the truncation point.
This appears to be a regression. React Native used to have logic similar to what this commit is adding: https://github.com/facebook/react-native/blob/1e2a924ba60001c6f0587c7561536f00b2922cbf/Libraries/Text/RCTShadowText.m#L186-L192
**Before fix**
Inline view (blue square) is visible even though it appears after the truncation point:
The full text being rendered was:
```
<Text numberOfLines={1}>
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna
<View style={{width: 50, height: 50, backgroundColor: 'steelblue'}} />
</Text>
```
**After fix**
Inline view is properly truncated:
**Test Plan**
Tested that the inline view is hidden if it appears after the truncation point when `numberOfLines` is 1 and 2. Similarly, verified that the inline view is visible if it appears before the truncation point.
**Release Notes**
[IOS] [BUGFIX] [Text] - Fix case where inline view is visible even though it should have been truncated
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/react-native/pull/21456
Differential Revision: D10182991
Pulled By: shergin
fbshipit-source-id: a5bddddb1bb8672b61d4feaa04013a92c8224155
Summary:
This fixes#19193
Characters of different languages may have different height and different baseline, even with a same font and same font-size. When they mixed together, iOS will adjust their baselines automatically, to display a suitable view of text.
The problem is the behavior of dealing with the text-style property 'lineHeight'.
It once to be a right way at version 0.52.3, to setting a base-line-offset attribute for the whole range of the string. However, in current version, it enumerated the string, and set a different base-line-offset for different font-height characters.
And this behavior broke the baseline adjustment made by the iOS. It just make every character's baseline aligned to a same line. But it is not supposed to displaying characters of different languages like that. Chinese characters' baseline is the bottom of each, however, it is not for English characters.
So maybe it is the better way to give a same value of base-line-offset attribute for the whole string. And this PR just did that: found the biggest value of font-height in the text, and calculate the offset with that biggest value, then set to the whole string. This will keep the origin baseline adjustment for different languages' chars made by iOS.
Since I always got an error when running the snapshot test locally, I can't even pass the them with the unmodified code in master branch.
The error is "Nesting of \<View\> within \<Text\> is not currently supported."
After I comment all of the check of that error from the source code, I got a different snapshot from the reference ones. It seems that all components which will cause that error are not rendered in the reference images.
Since this PR changed the behavior of 'lineHeight' property, it's better to add a new snapshot case for the situation of different-language-characters' mixture. So maybe somebody could help me with that or maybe it should be a issue?
[IOS] [BUGFIX] [Text] - fix the baseline issue when displaying a mixture of different-language characters
Pull Request resolved: https://github.com/facebook/react-native/pull/19653
Differential Revision: D10140131
Pulled By: shergin
fbshipit-source-id: 646a9c4046d497b78a980d82a015168cf940646b
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary: This adds a callback for <Text> to get metrics about the rendered text. It's divided by line but that could be changed to "fragments" (which makes more sense for multi-lingual). Right now by line is convenient as you frequently want to know where the first and last line end (though we could make this work with fragments I suppose).
Reviewed By: shergin
Differential Revision: D9440914
fbshipit-source-id: bb011bb7a52438380d3f604ffe7019b98c18d978
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
Fixing of recent regression in layout system.
Conseptually, a superview should define frames of child views.
Reviewed By: mmmulani
Differential Revision: D6980128
fbshipit-source-id: e267e966fd46af28db1d3d40939110040b74e33f
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: `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:
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:
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
Adam Comella
BingBing
Héctor Ramos
Mehdi Mulani
Valentin Shergin
Sophie Alpert
Spencer Ahrens
