[iOS][TextInput] Apply the fix for CJK languages on single-line text fields.

[mandrigin]

Follow-up to #19809

This fix generalizes the setAttributedString: fix to single-line text fields.

Fixes #19339

Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!

Test Plan:

⚠️ Possible areas of regressions: formatting of single-line text fields.

The test app

import React, {Component} from 'react';
import {StyleSheet, Text, TextInput, View} from 'react-native';

type Props = {};
export default class App extends Component<Props> {
    constructor(props) {
        super(props);
        this.state = { text: '', textM: '' };
    }
    render() {
        return (
            <View style={styles.container}>
            <Text style={styles.instructions}>SINGLE_LINE</Text>
            <TextInput
                style={{height: 40, width: 200, borderWidth: 1}}
                onChangeText={(text) => this.setState({text: text})}
                value={this.state.text}
            />
            <Text style={styles.instructions}>MULTILINE</Text>
            <TextInput
                style={{height: 40, width: 200, borderWidth: 1}}
                multiline={true}
                onChangeText={(text) => this.setState({textM: text})}
                value={this.state.textM}
            />
            </View>
        );
    }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    paddingTop: 100,
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  instructions: {
    textAlign: 'center',
    color: '#333333',
    marginBottom: 5,
    marginTop: 20,
  },
});

Essentially, the steps to reproduce are described in the issue:

• For both single-line and multi-line text fields:
  • Type some Korean characters in TextInput, such as "하늘" (buttons ㅎ,ㅏ,ㄴ,ㅡ,ㄹ).
  • Then move the cursor to the beginning of the text, type "파란" (buttons ㅍ,ㅏ,ㄹ,ㅏ,ㄴ) this time.

Behaviour before this fix
Actual text (Single-line): ㅍㅏㄹㅏㄴ하늘.
Actual text (Multi-line): 파란하늘.
Expected text (both fields): 파란하늘.
Characters aren't combined properly in single-line.

Behaviour after this fix (correct)
Actual text (Single-line): 파란하늘.
Actual text (Multi-line): 파란하늘.
Expected text (both fields): 파란하늘.
Characters are combined correctly.

Changelog:

[IOS] [BUGFIX] [TextView] - Fix Korean/Chinese/Japanese input for single-line TextView on iOS.

[shergin]

Why can't we move all this logic inside -[RCTUITextView setAttributedText] (which might imply adding sanitizing inside the getter. And same thing for UITextField subclass.

There is a huge reason for that desire: This module is the most complex module in the whole RN rendering subsystem. We have to push all logic that might be considered as "improvements of core UIKit components" down to subclasses dedicated for that. The reason is that our RN-specific model of the world implies that our expectations about how UIKit works are correct. That's really challenging to implement the ideal modal itself, so we cannot afford polluting that with UIKit specific fixes. We have to decouple them in subclasses that "fix" UIKit stuff for us.

[shergin]

Why can't we move all this logic inside -[RCTUITextView setAttributedText] (which might imply adding sanitizing inside the getter. And same thing for UITextField subclass.

There is a huge reason for that desire: This module is the most complex module in the whole RN rendering subsystem. We have to push all logic that might be considered as "improvements of core UIKit components" down to subclasses dedicated for that. The reason is that our RN-specific model of the world implies that our expectations about how UIKit works are correct. That's really challenging to implement the ideal modal itself, so we cannot afford polluting that with UIKit specific fixes. We have to decouple them in subclasses that "fix" UIKit stuff for us.

[shergin]

@mandrigin I deeply appreciate your effort and I am existed about those fixes. We struggled with them for so long time! But we really need to do it right to make it sustainable.

[mandrigin]

@shergin it is easier to me to comment here, to show why I did it this way.
UITextField is a very basic UI element. It doesn't expose any API to just change the string attributes without re-setting the attributed string completely (and breaking CJK input).
Luckily, it relies on it's own public (and overridable) property attributedText when rendering.

What I'm doing here is hijacking this property and replacing its value with the value I store locally, in NSMutableAttributedString, which I can replace without noticeable side-effects. So this override has to be here, if we want to continue to use UITextField. It's a hack and it can potentially break with new iOS releases, etc.

To be able to consolidate logic, we can just use UITextView everywhere, it provides all the necessary functionality as public APIs. What is the history between having 2 different implementations for single and multiline text views?

[shergin]

I mean why not consolidate all attribute specific-logic in this class making attributedText and setAttributedText behave as we want?

We have to have two different underlying components because they simply behave differently. There is no way to configure UITextView behave exactly as UITextField.

[shergin]

I mean we have an original problem: When we call setAttributedText, marked fragment gets reset. So, let's add all checks that prevents that into both RCTUITextField and RCTUITextView (iirc, now we have only one of them).

[mandrigin]

ah, okay, I mistread your initial comment.
So you mean, just duplicate the logic and encapsulate it inside RCTUITextField and RCTUITextView classes separately, so we can call setAttributedString safely on both RCTUITextField and RCTUITextView?

[mandrigin]

should be fixed now

[shergin]

(Let's continue discussion here.)
Now we are abstracted from anything else, so we can work on it. 😄

I think, it's great. ❤️

Nits:

• Instead of referring issues and commenting every single line, we have to leave one comment that describe a problem and (most importantly) the change in the behavior of the methods. That's more sustainable and easy to understand for people from the future which don't have a full context.
• Codestyle. (New line before { and spaces.)

Btw, I don't think it's only fix for CJK problem. It's more wide problem which happens when we are replacing some attributed string with completely new one without paying attention to what attributes were added to the string by active text input. So, if we can preserve those attributes, I bet full replacing will work with CJK. (The current solution is good enough though.)

[mandrigin]

pushed the fix to address this feedback

[mandrigin]

@shergin is there anything else I need to fix in this PR?

[shergin]

I mean why not to fallback to copyAttributesFrom here, if we see that super.attributedText.string === attributedText?

[mandrigin]

should be fixed now

[mandrigin]

@shergin I just simplified my fix to affect only one source file.

[facebook-github-bot]

@shergin is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[facebook-github-bot]

@shergin is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.