Editable Component #18361

ellatrix · 2019-11-07T08:46:11Z

Description

Alternative to #18238.
Fixes #13570.

This PR introduces a new Editable component, which purpose is to edit text without any formatting. It won't allow any formatting, nor will it have formatting controls. If any HTML tags are present, they are just rendered as text, not as text formatting.

The behaviour is much the same as a plain textarea, but there are a few advantages:

This component has native autoresizing.
It has the same RichText APIs: onSplit, onReplace, onRemove, onMerge.
Autocomplete works.
Annotation work, and editorial comments would work.
Selection is stored just like RichText's, which means it could be used for collaborative editing.
It shares the same undo/redo logic as RichText.

Under the hood, it's just RichText where formats are disabled, since a lot of the code can be shared. In the future, we could refactor this a bit and split out all the formatting logic, but for now, this works just fine. I could see Editable become the base component for RichText.

Sharing the codebase will eventually make the experience more streamlined. API improvements for text will benefit rich text, and improvements for rich text will benefit text.

I updated the site title block to use this component.

How has this been tested?

Try out the site title block.

Screenshots

Types of changes

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

youknowriad

Any thoughts about PlainText? Should we deprecate it, should we create a shortcut?

Copons · 2019-11-11T13:48:23Z

Any thoughts about PlainText? Should we deprecate it, should we create a shortcut?

I think with Text at this point the only use case for PlainText is as a wrapper for TextareaAutosize.

(@ellatrix I'm so sorry for not having reviewed this yet, but I've been swamped with new urgent tasks!)

youknowriad · 2019-11-12T09:01:10Z

packages/block-editor/src/components/rich-text/index.js

@@ -65,6 +65,7 @@ class RichTextWrapper extends Component {
 		this.onPaste = this.onPaste.bind( this );
 		this.onDelete = this.onDelete.bind( this );
 		this.inputRule = this.inputRule.bind( this );
+		this.getAllowedFormats.EMPTY_ARRAY = [];


Why not just a module constant

This empty array should be used specifically for the allowed formats state. I don't see a reason to make it a module constant. It isn't and shouldn't be reused for other state.

Would having a more declarative name be of any help? E.g. this.getAllowedFormats.NO_FORMATS = []

I can also use a module variable and name it differently. I just have this habit of putting stuff close to what is using it.

youknowriad · 2019-11-12T09:04:06Z

packages/block-editor/src/components/rich-text/index.js

+		const {
+			allowedFormats,
+			formattingControls,
+			__unstableDisableFormats,


Instead of having these disbleFormats props which doesn't make sense for a RichText component, ideally RichText should be a special version of Text. how feasable is that?

Why does it not make sense for RichText? I think it's fine.

It's harder right now to make RichText a wrapper around Text, but yes, in the future this could be done. To keep things simple with a minimum amount of code changes, I chose to use RichText internally in Text, but that can be refactored later.

I guess we could just make it a stable prop and omit __unstable. Maybe I'm being too prudent in introducing new props.

I agree with @ellatrix.
This is a great starting point: it makes things very straightforward, and doesn't prevent an eventual Text/RichText "switcheroo".

In my mind ideally disableFormats could be a valid prod for a low-level Text component that is used by higher-level PlainText and RichText components. So I think it doesn't make sense for RichText because RichText by definition is for Rich Text which means "formats".

I get that the refactor can be achieved later and is probably not that easy so unstable is better.

@youknowriad Oh, I'm sorry, I confused disableFormats and disableLinebreaks. I thought you were talking about the line breaks. Sorry about that. You're right, the prop doesn't make sense on RichText at all, it's just a stepping stone for now.

youknowriad · 2019-11-12T09:05:24Z

packages/block-editor/src/components/rich-text/index.js

-			onChange( insert( value, '\n' ) );
+			if ( ! disableLineBreaks ) {
+				onChange( insert( value, '\n' ) );
+			}


While reading the changes here, I was wondering why these onEnter handlers are block-editor specific and not something for the regular RichText component?

Inserting line breaks on enter could be a default feature of RichText (in the rich text package), sure. But it should also be overridable. Right now there's just no default handling. Maybe in a future PR.

youknowriad · 2019-11-12T09:06:02Z

packages/block-editor/src/components/text/index.js

+ */
+import RichText from '../rich-text';
+
+function Text( props ) {


Should we name this PlainText instead.

See #18361 (comment).

ellatrix · 2019-11-12T13:05:27Z

@youknowriad @Copons PlainText is already taken. Do you see a way around that? I don't mind plainly Text. It's plain enough to me.

youknowriad · 2019-11-12T13:09:27Z

If the APIs are compatible why not just replace the existing PlainText?

ellatrix · 2019-11-12T13:16:12Z

@youknowriad because, until now, PlainText was just a textarea that autoresizes. I guess developers are expecting it to be a textarea now. I don't know if it's fine to change blocks currently using PlainText as it will look different (textarea style vs "invisible" style). I'm fine either way though.

Copons · 2019-11-12T13:17:08Z

packages/block-editor/README.md

@@ -422,6 +422,10 @@ _Type_

 -   `Object` 

+<a name="Text" href="#Text">#</a> **Text**
+
+Renders an editable text input in which text formatting is not allowed.


I think this might be misinterpreted as an <input type="text">.
What about being more candid and go with something like Renders a contenteditable element in which text formatting is not allowed?

Yes, we need better descriptions. The mobile team previously reminded me not to use contenteditable as that's not the case for the native apps. @hypest @SergioEstevao @Tug and maybe others (not sure if @WordPress/native-mobile works), what would be a good description? :)

We should also update the RichText description. :)

Also Text might be confusing because in react-native it's a display-only component. For this, react-native uses TextInput:

A foundational component for inputting text into the app via a keyboard. Props provide configurability for several features, such as auto-correction, auto-capitalization, placeholder text, and different keyboard types, such as a numeric keypad

Sorry I'm a bit late to the conversation, I'd vote for TextInput since it would have very similar behavior as the react-native component @koke talked about.

youknowriad · 2019-11-12T13:17:35Z

@ellatrix Good point. I'd love other thoughts here @mcsf @aduth

youknowriad · 2019-11-12T13:19:41Z

If PlainText is just an autosizeable textarea, there's no need for a component for it, you can just use TextareaAutosize. That the reason I think naming this PlainText makes sense. For me PlainText has always been the equivalent of RichText with non-formatted code. I can see how this can be consider a breaking change somehow, maybe fine with a Dev Note?

Copons · 2019-11-12T13:23:08Z

packages/block-editor/src/components/text/README.md

@@ -0,0 +1,114 @@
+# `Text`
+
+Renders an editable text input in which text formatting is not allowed.


See https://github.com/WordPress/gutenberg/pull/18361/files#r345198111

ellatrix · 2019-11-12T13:25:32Z

@youknowriad Ok, sounds good to me. I was just being careful. :) It's worth noting though that other (not listed) textarea props will no longer work, for example rows (which doesn't make much sense when it autoresizes). I guess we should be extra clear about that in the dev note.

Copons · 2019-11-12T13:28:07Z

What about keeping PlainText as a wrapper for TextareaAutosize, in the off chance we eventually want to replace it with another component (external or not)?

ellatrix · 2019-11-12T13:36:54Z

@youknowriad @Copons Looking at PlainText again, I see that the web and native version of it have diverged so much, I'm not sure why. It has several font* props.

gutenberg/packages/block-editor/src/components/plain-text/index.native.js

Lines 41 to 54 in e9fcbdc

    
           <TextInput 
        
           	{ ...this.props } 
        
           	ref={ ( x ) => this._input = x } 
        
           	className={ [ styles[ 'block-editor-plain-text' ], this.props.className ] } 
        
           	onChange={ ( event ) => { 
        
           		this.props.onChange( event.nativeEvent.text ); 
        
           	} } 
        
           	onFocus={ this.props.onFocus } // always assign onFocus as a props 
        
           	onBlur={ this.props.onBlur } // always assign onBlur as a props 
        
           	fontFamily={ this.props.fontFamily || ( styles[ 'block-editor-plain-text' ].fontFamily ) } 
        
           	fontSize={ this.props.fontSize } 
        
           	fontWeight={ this.props.fontWeight } 
        
           	fontStyle={ this.props.fontStyle } 
        
           />

I would feel more comfortable starting a new component.

ellatrix · 2019-11-14T09:39:14Z

packages/block-editor/src/components/rich-text/index.js

@@ -73,6 +74,7 @@ class RichTextWrapper extends Component {
 			onSplit,
 			multiline,
 			markAutomaticChange,
+			disableLineBreaks,


This prop addressed #13570.

mcsf · 2019-11-18T11:23:17Z

If PlainText is just an autosizeable textarea, there's no need for a component for it, you can just use TextareaAutosize. That the reason I think naming this PlainText makes sense. For me PlainText has always been the equivalent of RichText with non-formatted code. I can see how this can be consider a breaking change somehow, maybe fine with a Dev Note?

@ellatrix, @youknowriad: what about a deprecation cycle like so:

Rename Text to PlainText. For new uses of PlainText (i.e. as a native component), developers should use a prop like <PlainText version={ 2 } /> or whatever. Whenever the prop is not used, we can assume it's deprecated usage, and we raise a deprecate warning telling devs to either add the prop or switch to textarea.
After one WP major, we drop the requirement for the version prop and drop compatibility with textarea.

youknowriad · 2019-11-18T11:30:02Z

@mcsf That sounds interesting. I think I like it. it does create a precedent in terms of backward compatibility handling. At the moment, deprecated calls are never removed. I think they should be at some point, but it's hard to have these discussions properly, how many versions should we wait before removing the deprecated usage...

This is though a very "smallish" breaking change (just a styling one), so I don't think it would be a huge deal.

ellatrix · 2019-11-18T14:41:33Z

@hypest @SergioEstevao Why are there font* props on the native version of the PlainText block? Why is this not a style object?

SergioEstevao · 2019-11-21T17:56:37Z

@hypest @SergioEstevao Why are there font* props on the native version of the PlainText block? Why is this not a style object?

So I had a look on this and we don't need to use props we could get them from the style object.
The style object itself can be used directly on TextInput, except for the fontFamily that needs a specific prop but this can be done like this:

render() {
		const style = this.props.style || styles[ 'block-editor-plain-text' ]
		return (
			<TextInput
				{ ...this.props }
				ref={ ( x ) => this._input = x }
				// className={ [ styles[ 'block-editor-plain-text' ], this.props.className ] }
				onChange={ ( event ) => {
					this.props.onChange( event.nativeEvent.text );
				} }
				onFocus={ this.props.onFocus } // always assign onFocus as a props
				onBlur={ this.props.onBlur } // always assign onBlur as a props
				style= { style }
				fontFamily={ style.fontFamily }
				// fontSize={ this.props.fontSize }
				// fontWeight={ this.props.fontWeight }
				// fontStyle={ this.props.fontStyle }
			/>
		);
	}

ellatrix · 2019-11-21T20:14:16Z

@SergioEstevao What does font family need a separate prop?

epiqueras · 2020-01-31T12:43:47Z

The site title block looks good to me.

github-actions · 2020-03-18T17:09:14Z

Size Change: -889 B (0%)

Total Size: 856 kB

Filename	Size	Change
`build/block-editor/index.js`	100 kB	+157 B (0%)
`build/block-library/index.js`	110 kB	-1.1 kB (1%)
`build/rich-text/index.js`	14.4 kB	+59 B (0%)

ℹ️ View Unchanged

Filename	Size	Change
`build/a11y/index.js`	998 B	0 B
`build/annotations/index.js`	3.43 kB	0 B
`build/api-fetch/index.js`	3.39 kB	0 B
`build/autop/index.js`	2.58 kB	0 B
`build/blob/index.js`	620 B	0 B
`build/block-directory/index.js`	6.02 kB	0 B
`build/block-directory/style-rtl.css`	760 B	0 B
`build/block-directory/style.css`	760 B	0 B
`build/block-editor/style-rtl.css`	10.9 kB	0 B
`build/block-editor/style.css`	10.9 kB	0 B
`build/block-library/editor-rtl.css`	7.23 kB	0 B
`build/block-library/editor.css`	7.24 kB	0 B
`build/block-library/style-rtl.css`	7.42 kB	0 B
`build/block-library/style.css`	7.43 kB	0 B
`build/block-library/theme-rtl.css`	669 B	0 B
`build/block-library/theme.css`	671 B	0 B
`build/block-serialization-default-parser/index.js`	1.65 kB	0 B
`build/block-serialization-spec-parser/index.js`	3.1 kB	0 B
`build/blocks/index.js`	57.5 kB	0 B
`build/components/index.js`	191 kB	0 B
`build/components/style-rtl.css`	15.7 kB	0 B
`build/components/style.css`	15.7 kB	0 B
`build/compose/index.js`	6.21 kB	0 B
`build/core-data/index.js`	10.6 kB	0 B
`build/data-controls/index.js`	1.04 kB	0 B
`build/data/index.js`	8.2 kB	0 B
`build/date/index.js`	5.37 kB	0 B
`build/deprecated/index.js`	771 B	0 B
`build/dom-ready/index.js`	568 B	0 B
`build/dom/index.js`	3.06 kB	0 B
`build/edit-post/index.js`	91.2 kB	0 B
`build/edit-post/style-rtl.css`	8.47 kB	0 B
`build/edit-post/style.css`	8.46 kB	0 B
`build/edit-site/index.js`	5.56 kB	0 B
`build/edit-site/style-rtl.css`	2.62 kB	0 B
`build/edit-site/style.css`	2.62 kB	0 B
`build/edit-widgets/index.js`	4.43 kB	0 B
`build/edit-widgets/style-rtl.css`	2.58 kB	0 B
`build/edit-widgets/style.css`	2.58 kB	0 B
`build/editor/editor-styles-rtl.css`	381 B	0 B
`build/editor/editor-styles.css`	382 B	0 B
`build/editor/index.js`	43.8 kB	0 B
`build/editor/style-rtl.css`	3.97 kB	0 B
`build/editor/style.css`	3.96 kB	0 B
`build/element/index.js`	4.44 kB	0 B
`build/escape-html/index.js`	733 B	0 B
`build/format-library/index.js`	6.95 kB	0 B
`build/format-library/style-rtl.css`	502 B	0 B
`build/format-library/style.css`	502 B	0 B
`build/hooks/index.js`	1.93 kB	0 B
`build/html-entities/index.js`	621 B	0 B
`build/i18n/index.js`	3.49 kB	0 B
`build/is-shallow-equal/index.js`	711 B	0 B
`build/keyboard-shortcuts/index.js`	2.3 kB	0 B
`build/keycodes/index.js`	1.69 kB	0 B
`build/list-reusable-blocks/index.js`	2.99 kB	0 B
`build/list-reusable-blocks/style-rtl.css`	226 B	0 B
`build/list-reusable-blocks/style.css`	226 B	0 B
`build/media-utils/index.js`	4.83 kB	0 B
`build/notices/index.js`	1.58 kB	0 B
`build/nux/index.js`	3.01 kB	0 B
`build/nux/style-rtl.css`	616 B	0 B
`build/nux/style.css`	613 B	0 B
`build/plugins/index.js`	2.54 kB	0 B
`build/primitives/index.js`	1.5 kB	0 B
`build/priority-queue/index.js`	780 B	0 B
`build/redux-routine/index.js`	2.83 kB	0 B
`build/server-side-render/index.js`	2.55 kB	0 B
`build/shortcode/index.js`	1.7 kB	0 B
`build/token-list/index.js`	1.27 kB	0 B
`build/url/index.js`	4.01 kB	0 B
`build/viewport/index.js`	1.61 kB	0 B
`build/warning/index.js`	1.14 kB	0 B
`build/wordcount/index.js`	1.18 kB	0 B

_{compressed-size-action}

ellatrix · 2020-03-19T09:18:03Z

Let's do this and iterate.

youknowriad · 2020-03-19T09:20:15Z

I personally still have concerns on the naming, and since this is a new API, maybe we should take time to discuss it properly.

ellatrix · 2020-03-19T09:22:39Z

@youknowriad Ok, sorry. It's just been sitting around for a long time and I didn't feel there were big objections. Shall I revert?

youknowriad · 2020-03-19T09:27:07Z

@ellatrix funny enough I was looking at the PR today before you merge it :)

The Editable name is something we already used a long time ago in Gutenberg for RichText and it has a potential of creation confusion IMO (some plugins, docs still use it)

I'm still leaning towards PlainText replacement personally. @mcsf sounded good. but let's not rush the revert. Give it some time for folks to chime in.

ellatrix · 2020-03-19T09:32:46Z

Well, if Text was not descriptive enough, and is now clashing with another component for displaying text, so can PlainText and RichText. PlainText doesn't describe something being editable. Alternatively we could have EditablePlainText or <Editable plainText> or something, but I think editable is key in communicating what the component does. I think we should eventually make an alias for RichText too.

youknowriad · 2020-03-19T10:03:10Z

It seems we don't agree on the Editable name but we agree on needing a low-level component to share code between Rich and Plain (whatever you call it) component. Since PlainText is already an existing API, why not update it to use the Editable component without exposing it for now.

mtias · 2020-03-19T12:06:45Z

I don't find the Editable particularly illuminating. It's probably more confusing to me since it has no context what it is editing — in an editor, everything is assumed to be editable. For media we don't have EditableMedia components, etc.

RichText for me is a good name. What is the other use of Text that we are clashing with?

ellatrix · 2020-03-19T12:57:56Z

@mtias https://github.com/WordPress/gutenberg/tree/master/packages/components/src/text#readme

ZebulanStanphill · 2020-03-19T18:33:00Z

Why not call this component "EditableText"? "Editable" isn't that clear; editable what?

youknowriad · 2020-03-20T10:12:16Z

Ideally, we find a solution here before the next plugin release (monday).

ellatrix · 2020-03-20T10:38:05Z

I’ll rename the component today and alias it to plaintext version 2? Op vr 20 mrt. 2020 om 11:12 schreef Riad Benguella <[email protected]

…

Ideally, we find a solution here before the next plugin release (monday). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABD6B2ZOU2CRFOQTKEJC5SLRIM6RDANCNFSM4JKDJLHQ> .

youknowriad · 2020-03-20T10:39:58Z

@ellatrix That works for me but it can wait until Monday, I know you're AFK today.

ellatrix requested review from ajitbohra, daniloercoli, etoledom, jorgefilipecosta, SergioEstevao, Soean, talldan and youknowriad as code owners November 7, 2019 08:46

ellatrix requested a review from Copons November 7, 2019 08:46

ellatrix mentioned this pull request Nov 7, 2019

PlainText: Add multiline and isStylable props #18238

Closed

5 tasks

youknowriad reviewed Nov 11, 2019

View reviewed changes

youknowriad reviewed Nov 12, 2019

View reviewed changes

Copons reviewed Nov 12, 2019

View reviewed changes

Copons mentioned this pull request Nov 13, 2019

Full Site Editing: Add experimental SiteDescription block #18241

Closed

5 tasks

ellatrix commented Nov 14, 2019

View reviewed changes

ellatrix requested review from Copons, youknowriad and epiqueras January 31, 2020 12:30

ellatrix added 3 commits March 18, 2020 17:36

Text Component

88030db

Rename

12f992e

Lint fixes

a8855d2

ellatrix force-pushed the try/text branch from 7d4977b to a8855d2 Compare March 18, 2020 17:04

ellatrix merged commit 0446ed1 into master Mar 19, 2020

ellatrix deleted the try/text branch March 19, 2020 09:18

github-actions bot added this to the Gutenberg 7.8 milestone Mar 19, 2020

ellatrix mentioned this pull request Mar 23, 2020

PlainText v2 #21076

Merged

6 tasks

Copons mentioned this pull request Apr 28, 2020

Button Block: Properly render inner HTML if context-appropriate Automattic/jetpack#15595

Merged

ellatrix mentioned this pull request Jul 3, 2020

Dev Notes for WP 5.5 #23669

Closed

12 tasks

ellatrix removed the Needs Dev Note Requires a developer note for a major WordPress release cycle label Jul 16, 2020

ockham mentioned this pull request Aug 24, 2020

Restore Site Title's Level toolbar and remove obsolete code #24758

Merged

6 tasks

ZebulanStanphill mentioned this pull request Mar 21, 2022

react-autosize-textarea dependency seems to be abandoned; what does this mean for <PlainText>? #39619

Open

		@@ -0,0 +1,114 @@
		# `Text`

		Renders an editable text input in which text formatting is not allowed.

Editable Component #18361

Editable Component #18361

Conversation

ellatrix commented Nov 7, 2019 • edited Loading

Description

How has this been tested?

Screenshots

Types of changes

Checklist:

youknowriad left a comment

Choose a reason for hiding this comment

Copons commented Nov 11, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ellatrix commented Nov 12, 2019

youknowriad commented Nov 12, 2019

ellatrix commented Nov 12, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented Nov 12, 2019 • edited Loading

youknowriad commented Nov 12, 2019

Choose a reason for hiding this comment

ellatrix commented Nov 12, 2019

Copons commented Nov 12, 2019

ellatrix commented Nov 12, 2019 • edited Loading

Choose a reason for hiding this comment

mcsf commented Nov 18, 2019

youknowriad commented Nov 18, 2019

ellatrix commented Nov 18, 2019

SergioEstevao commented Nov 21, 2019

ellatrix commented Nov 21, 2019

epiqueras commented Jan 31, 2020

github-actions bot commented Mar 18, 2020

ellatrix commented Mar 19, 2020

youknowriad commented Mar 19, 2020

ellatrix commented Mar 19, 2020

youknowriad commented Mar 19, 2020

ellatrix commented Mar 19, 2020

youknowriad commented Mar 19, 2020

mtias commented Mar 19, 2020

ellatrix commented Mar 19, 2020

ZebulanStanphill commented Mar 19, 2020

youknowriad commented Mar 20, 2020

ellatrix commented Mar 20, 2020 via email

youknowriad commented Mar 20, 2020

ellatrix commented Nov 7, 2019 •

edited

Loading

youknowriad commented Nov 12, 2019 •

edited

Loading

ellatrix commented Nov 12, 2019 •

edited

Loading