Improve reusable block creation flow #5428
Conversation
When a reusable block is created, immediately put it into editing mode and select the title <input>. This reduces the amount of steps required to create a reusable block.
noisysocks
added
[Type] Enhancement
| @@ -10,66 +11,97 @@ import { keycodes } from '@wordpress/utils'; | |||
| */ | |||
| import './style.scss'; | |||
|
|
|||
| /** | |||
There was a problem hiding this comment.
FWIW I don't think it's so bad in this case, because it's fairly obvious what ESCAPE is, but I dislike the idea of a "Module constants" docblock in general, because it normalizes the idea that we don't need to document variables we define, and can instead apply a blanket grouping to them.
There was a problem hiding this comment.
I'll leave this for now since we do this in a few places and I'd prefer we're somewhat consistent. It might be worth going through and auditing our usage of this pattern, since you raise a really good point.
| this.titleRef = ref; | ||
| } | ||
|
|
||
| componentDidMount() { |
There was a problem hiding this comment.
Conventionally like to see all component lifecycle following the constructor, with no functions in between.
There was a problem hiding this comment.
👌 I've moved it in c7e444f.
blocks/library/block/index.js
Outdated
| @@ -27,8 +27,10 @@ class ReusableBlockEdit extends Component { | |||
| this.setTitle = this.setTitle.bind( this ); | |||
| this.updateReusableBlock = this.updateReusableBlock.bind( this ); | |||
|
|
|||
| const { reusableBlock } = this.props; | |||
There was a problem hiding this comment.
I'd thought this not to work in constructor, since props is otherwise passed as the first argument of the constructor function. Not sure if there's a strong consensus on whether this should be discouraged though.
There was a problem hiding this comment.
If nothing else, it's simpler! Fixed in 5af814e.
| ( ! isEditing && ! isSaving ) && ( | ||
| <div key="view" className="reusable-block-edit-panel"> | ||
| <span className="reusable-block-edit-panel__info"> | ||
| <b>{ title }</b> |
There was a problem hiding this comment.
Of course not relevant to this pull request, but was <b> chosen for a particular reason?
Do not confuse the element with the , , or elements. The element represents text of certain importance, puts some emphasis on the text and the element represents text of certain relevance. The element doesn't convey such special semantic information; use it only when no others fit.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b
Further, do we need both the span and the b, or could we collapse to eliminate one or the other (probably just replacing span with desired inline tag).
There was a problem hiding this comment.
Eliminated the unnecessary <span> in 3b92ad5. I like the <b> in lieu of a <span> since it denotes that there's something special (well, bold...) about this text to the developer who is reading the JSX.
Move bindTitleRef so that the React lifecycle methods immediately follow the constructor.
There's no need, as we're passed props as the constructor's first argument.
Simplify the edit panel DOM tree by replacing <span><b /></span> with just the single <b>.
Description
Closes #4527.
Modifies the flow to create a reusable block to look like this:
This removes two steps from the flow of creating a reusable block.
Testing