fix: don't update text input text directly in setTextAndSelection

[hannojg]

Summary:

This is one possible solution to fix the flickering issue described here:

• iOS: Singleline TextInput auto grow: text gets cut while typing #46838

The main fix is that when we receive the view command call setTextAndSelection we don't want to update the attributedString on the backing TextField immediately, but update the state of the shadow node.
This way the layout for the view will be calculated with the updated state, and the updated text + updated layout will be applied at once.

Changelog:

[IOS] [FIXED] - Flicker when changing text in a dynamic sized TextInput

Test Plan:

Run the tester app and make sure that every TextInput example still works as before

I added another PR which adds an explicit example case to the RNTester app:

• add example for dynamic sized text input #46976

Before changes	After
Screen.Recording.2024-10-11.at.14.41.45.mov	Screen.Recording.2024-10-11.at.15.01.37.mov

[NickGerleman]

Description here seems different from code (where the main change is we are flushing event sync).

cc @sammy-SC for sync text events. Not sure what our end goal is for them (we want to move more to sync, to avoid the sorts of issues here), but it’s not free.

[hannojg]

Yes, so its two changes:

1. Flushing events sync (so the layout gets updated immediately). This is necessary for when the user is typing, ie. the text changes are coming from the native host component (textInputDidChange)
2. There is a second use-case, which is where the events are coming from JS (controlled input). There the problem is that we updated the host component without going through the shadow tree, ie. we are setting text without updating the layout, which we should never do i assume (see previous explanation here).

[sammy-SC]

the API is not ready for a general adoption. We are still iterating on the design and trying to prove its usefulness in production.

[hannojg]

okay, then lets hide it behind a feature flag?

[sammy-SC]

let me share little more context :)

First of all, the the general approach you are taking here is good. This is one of issues that sync events can fix as React Native will no longer need to do the round trip from the main thread to JS thread and back to main thread, resulting in unpleasant flicker.

As the method name suggests, the sync events are still experimental. We are not sure what the right API is at the moment. We are focusing on making the new architecture the default before fully embracing the new capabilities that is potentially breaking. experimental_flushSync works great in isolated cases but might lead to dropped frames when the JS thread is busy. We currently don't have good tools to help engineers find what the main thread is blocked on.

Once we have a good design for sync events, it will fix some issues with TextInput and significantly simplify the implementation.

[react-native-bot]

This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.

[react-native-bot]

This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.