Gutenberg-mobile: Minimize handling of changes made into AztecText

[mzorz]

As per #60, when the user enters text into an the RN-wrapped version of AztecText RCTAztecView currently, each change is saved to the application's state with each keystroke, and such an event was being reflected back into Aztec as per the binding of text={ this.props.attributes.content } in RCTAztecView. This was made apparent in #60 and the performance problems were fixed _on Android only_ by #62, by filtering which events to consider and which not, and provided a variable that counts events is shared and sent back and forth to/from Java/Javascript code.

An approach we could take in order to avoid this, but foremost, avoid changing the app's state on each keystroke is to use the ReactAztecFocusEvent and ReactAztecEndEditingEvent events (or, if needed, base it on a different event altogether - just naming the events we already have up to date) to control when to update the state only, instead of making each TextChange event reflect on the RN kept state in this case. This at first is counterintuitive in terms of the React logic, but it rings as something plausible given the performance issues we'll be facing, and is a "pure JS" solution (as opposed to involving platform-specific code like Java and more Js/Java interaction controlling code, and the needed handling code on the iOS counterpart).

I've made tests here just changing onChange for onEndEditing in line 84 in this experimental branch and it seems to work pretty well (no more lagging / weird refreshing issues). This, without the code in #62 and https://github.com/wordpress-mobile/react-native-aztec/pull/24

The potential problems that arise from this other approach are around the ability to keep up to date with the changes (that is, do not lose or alter content) in any other case, thinking some here:

• the state gets saved when focus is lost ✅ (when the component goes off screen)
• what happens when the app is sent to the background (either by the user or by something of priority happening, like a phone call for example)? ❓
• what happens when the app gets killed by the system? ❓
• what happens when the user rotates the screen? ❓
• ....
  Note: Aztec Android itself keeps its state when sent to the background / on screen rotation, so it seems we're safe in the cases above (we'd only need to peek AztecText and update the app's state when saving, but in a declarative/functional way). We still need to see if this is the same for Aztec iOS.

Copying here so we're aware only, but not to call immediate attention cc @SergioEstevao @diegoreymendez @daniloercoli @hypest

[koke]

From my limited knowledge, I think the right approach to this is to leverage shouldComponentUpdate to decide when we need to re-render.

I see some of that logic already in withSelect and @wordpress/element so we might even get that for free in the future, but I'm still a bit lost on that part.

[diegoreymendez]

The update issue is not specific to RN though, although I can imagine it'd be more apparent. I can't remember right now if we made improvements for this in WPiOS, but we had already spotted the need to avoid updating the post state and saving on each keystroke.

That said, I'm not too sure if the one to define the logic for saving should be the editor or the consuming app.

[hypest]

Another aspect to add is: who owns the undo history and what "chunks" of change are saved as a single undo record?

Currently, Aztec owns its editing history, including of course raw text modifications (versus, for example, styling changes). I think we will probably need to implement something clever there to efficiently store content changes in the RN/app state.

In that sense, I can't tell yet exactly when the Aztec instance should re-render or how often. I think I'd like to see some implementation of the undo/redo logic before forming an opinion.

[SergioEstevao]

@mchowning this looks related to: https://github.com/wordpress-mobile/gutenberg-mobile/issues/1941

[hypest]

The Aztec integration has changed quite a bit for some time now (with RichText component on the Gutenberg-web side) and this ticket is now hard to relate to any particular code part. The ticket was originally raised for visibility purposes so, closing now as out-of-date.