[iOS] Fixed maxLength of TextInput based on glyph count

[zhongwuzw]

Summary

Fixes #10964 #22463 .
We need changed maxLength to count glyph instead. Because like emoji, some language，it represents using multiple bytes, so if we limit using characters, would leads some weird bugs, like clear the line or glyph not show correctly.

cc. @cpojer .

Changelog

[iOS] [Fixed] - Fixed maxLength of TextInput based on glyph count

Test Plan

If we input one emoji, it needs to show correctly.

<TextInput maxLength={1} />

[shergin]

Are there any chances that we can restructure the code moving complexity of this particular feature to separate thing/class/function?

TextInput is very complex and fragile component. We have to try very hard to maintain the manageability of this complexity (yes it is already pretty poor but it was even worse).

Now, with this implementation, we have a hard dilemma: what's more important to us - this feature or regress of manageability?
This is hard choice.

[shergin]

We have to decouple that into separate file(s).

[zhongwuzw]

@shegin Is this what we want? 🤔 I restructure the code and consolidate max length handler into separate function.

[shergin]

I believe to land this feature we need to reduce complexity instead of increasing it.

Yes, it's challenging but that's the only sustainable way to progress.
I don't know how it can be done, but I believe it's possible having that e.g. - (BOOL)textInputShouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text is already pretty complex and clearly needs more love.

[shergin]

Not exactly.
This separate function is still a method (it mutates self) which does not solve the complexity problem.

[zhongwuzw]

@shergin Yeah, actually, Swift already solved this glyphs issue, but OC, we seems need to do these heavy things by ourself. Have no idea how to move on. 😂

[shergin]

Yeah, Swift's strings are character-aware but normal Objective-C are not. Yeah... but that's only String's properties, that is not related to UITextField and UITextView implementation, right? So, we already have two subclasses for those classes that enhance the behaviors and fix some issue. Maybe we can encapsulate that character-aware logic there?

Or, what if we move that maxLength feature implementation into those classes and try to make it totally transparent for all external logic?

[shergin]

❤️
Back to your queue.
I would love to land this feature, but we need to design it in a way that reduces complexity first.

[zhongwuzw]

@shergin
Hi :) I may need your some inputs, is this the right direction you wanted? 🤔

[cpojer]

I thought about this some more and we have a ton of code that on the backend expects maxLength to adhere to the real length and not the human readable length. Changing the default now and only for iOS will likely cause a lot of issues for us at Facebook and others.

If we want to solve this I think we may want to add another prop that explicitly specifies the max length is based on the glyph count instead of the number of bytes and make people opt-in to use that prop in the cases where the human readable length matters to them.

[zhongwuzw]

@cpojer 👌 We already improved TextInput so much, let's wait to see wether any user wants it, then we can add it. :)