Gutenberg-mobile: Paste multi-paragraph text in Post Title does nothing

[etoledom]

Pasting a multi-paragraph text into the Post Title currently does nothing.

This happens because PostTitle is based on RichText, and PostTitle doesn't have proper support for onSplit and onReplace.

The behavior on WEB is to paste all text as a single line in the Post Title, even if the copied text had multiple paragraphs.

[etoledom]

As a proposed solution, I think the best would be to not use RichText on PostTitle, since it is coupled with many block-specific behavior, including https://github.com/wordpress-mobile/gutenberg-mobile/issues/1033.

As an alternative, I implemented multi-paragraph pasting on PostTitle, on a similar way as it is implemented on Paragraph block: https://github.com/WordPress/gutenberg/compare/rnmobile/multi-paragraph-paste-on-post-title

The result is interesting:

• Pasting multi-paragraph content on Post Title will update the title field with the first paragraph, and create appropriate blocks for the rest one the paragraphs:

I think it might be a good thing, but it has its catches, like:

• Pasting multi-paragraph text in the middle of the post title, will split the post title content, leaving just the first half in the title. (as splitting a paragraph block). This might not be expected for users.
• Pasting multi-paragraph text at the end of the title with content, it won't add anything to the title and just add blocks.

Another possible solution would be to continue using RichText but to try to emulate the behavior on web. This will probably mean to add more custom code on RichText, which is not ideal.

---

I'd prefer to have the same behavior than web, by replacing RichText with other component (maybe a plane TextInput).

What do you think?
@hypest @daniloercoli @SergioEstevao

[SergioEstevao]

I'd prefer to have the same behavior than web, by replacing RichText with other component (maybe a plane TextInput).

This for sure! We are introducing a lot of custom behaviour in RichText because of this. If we can get rid of it it will be great!

[daniloercoli]

I'd prefer to have the same behavior than web, by replacing RichText with other component (maybe a plane TextInput).

This was discussed on Slack not long time ago, but thanks to open the discussion here after your findings.
Switching to TextInput is not possible at the moment, since Enter.key detection isn't working good on Android (Ref: https://facebook.github.io/react-native/docs/textinput#onkeypress). Note: on Android only the inputs from soft keyboard are handled, not the hardware keyboard inputs.

Some of most common keyboards, available on Android devices, identify themself to the Android platform as HW keyboard, so thus pressing enter.key isn't handled on them.

I see 2 solutions other then keep using our RichText:

• Extend RN TextInput and give it some basic Enter.key detection capability
• Use plain TextInput and its onSubmitEditing prop. Customize the Enter.key label in some way (We can set it to show ✔️ ) Ref: https://facebook.github.io/react-native/docs/textinput#returnkeytype
  Remember that once the user hits the submit button the keyboard is automatically closed, and there is no easy way to prevent that on Android. You can force re-open it later, but the animation close-open is shown to the user.

Question: Are we sure that using TextInput is a viable solution? should not we backport to TextInput other behaviors already implemented in RichText (other than enter.key detection)

[etoledom]

Switching to TextInput is not possible at the moment, since Enter.key detection isn't working good on Android

That sounds like a deal breaker.

I thought about creating a new simpler native component, that we can use for plain text edition, with all the customizations we need, but it can be time consuming to create and maintain (since it need effort on Android and iOS).

Another option could be to make this new and simpler component based on RCTAztecView. We could treat it as a Plain Text component but backed up by Aztec for styling and all the custom actions we need and already use on RichText, and no need for native development (hopefully).

I can experiment with this last option to see how real it is. We can literally make the PlaneText component already used on Code Block block use RCTAztecView. It's also used on HTML Block by web.

We can use it in all places where RichText is not really needed.

[etoledom]

Another option could be to make this new and simpler component based on RCTAztecView

Here is a draft PR that explores this possibility: https://github.com/wordpress-mobile/gutenberg-mobile/pull/1134

It uses PlainText based on Aztec. One down side is that PlainText might get affected by changes on the RichText-RCTAztec interface, but the interface doesn't change as often as RichText itself, or HTML related changes on Aztec/Wrapper, where PlainText should be immune to.

We were having already problems on PostTitle due to changes on RichText, and some custom code on RichText trying to solve PostTitle specific problems.

On the other hand, this PlainText implementation is much simpler than RichText, it's allow us to remove RichText from PostTitle, and still manage custom events properly. It was fairly easy to add onEnter, single and mult-paragraph pasting on singe and multi-line instances of PlainText.

The only other part that we are using PlainText so far is Code Block, that is not public. But it's now working with the same features than on Web.

(cc @hypest )

[etoledom]

Another alternative: Subclass TextInput:
https://github.com/wordpress-mobile/gutenberg-mobile/pull/1148

[hypest]

Not sure if you're actively working on this one @etoledom , if so, better to move the ticket to the "In Progress" column in the project board, otherwise let's un-assign the ticket. Thanks!

[etoledom]

UPDATE:

Tested again, and it is "partially" working. It does paste multi-paragraph text into the Post Title, but it behaves differently from Web, since it doesn't strip out the new lines characters.

This is fixed after publishing/updating, where all new lines are removed from the post title.

Would this be "good enough" for the open beta?
cc @hypest

[hypest]

During a planning session, we decided to let this out of the Open Beta at this stage.

[SergioEstevao]

The current behavior on the web is that if you paste multiline content, the first line stays on the title and the remaining content will inserted has new blocks after the title.