Show inserter on slash: /+SEARCH #2284
Conversation
ellatrix
force-pushed
the
try/slash-command
branch
from
9e10abf to
7cc8328
Compare
|
Something is still going wrong with the CSS here. Maybe because I'm cross-importing and it causes this? I wonder how I should improve this? Move |
Codecov Report
@@ Coverage Diff @@
## master #2284 +/- ##
==========================================
+ Coverage 24.06% 25.14% +1.08%
==========================================
Files 149 150 +1
Lines 4592 4955 +363
Branches 775 876 +101
==========================================
+ Hits 1105 1246 +141
- Misses 2946 3109 +163
- Partials 541 600 +59
Continue to review full report at Codecov.
|
|
@iseulde I think we should do a separate inserter component for this case—that just lists blocks in a single column list—instead of reusing the other. |
mtias
added
the
[Feature] Inserter
|
Probably call it blocks-autcomplete. And it would look closer to:
|
|
We should use the same design for eventually autocompleting tags, users, etc. |
|
@mtias Ok, I'll adjust |
|
Love this, thank you for working on it. I would agree with Matías, for this round 2 of the slash command, let's try adhering as closely as possible to the pattern from whence the inspiration came: Slack and IRC:
|
There was a problem hiding this comment.
I wonder how I should improve this? Move
InserterMenuto components? But then it still needs to be state aware? Make a special blocks folder ineditor/that is state aware (internal)? Note that this is not the only block, there will be blocks like table of contents that will also need to be state aware. Cc @youknowriad @aduth.
I agree, we will likely need better support for blocks components and perhaps blocks themselves having access to and manipulating state. Remarked previously at at #2119 (comment) and #2182 (comment) , I question whether our split between blocks and editor is sensible. I think there are post-editor specific concerns that might not be relevant to blocks and editors generally, but the idea of a block and editor should be unified, at which point the core of an editor consists of block APIs, components, and editor state itself. It becomes the editor chrome (headers, sidebars, etc) which might need to be externalized as a layer atop this core.
| } | ||
|
|
||
| // Merge text nodes. | ||
| editor.getBody().normalize(); |
There was a problem hiding this comment.
How expensive an operation is this for something which will occur on every single keypress? Edit: I guess it's every keypress for a block which implements onReplace (inserter block).
| @@ -11,7 +11,7 @@ import { __, _n, sprintf } from '@wordpress/i18n'; | |||
| import { Component } from '@wordpress/element'; | |||
| import { Popover, withFocusReturn, withInstanceId, withSpokenMessages } from '@wordpress/components'; | |||
| import { keycodes } from '@wordpress/utils'; | |||
| import { getCategories, getBlockTypes, BlockIcon } from '@wordpress/blocks'; | |||
| import { getCategories, getBlockTypes, BlockIcon } from '../../blocks'; | |||
|
|
||
| const { BACKSPACE, ESCAPE } = keycodes; | ||
|
|
||
| registerBlockType( 'core/inserter', { |
There was a problem hiding this comment.
I've not tested this, but what's the expected behavior with this being implemented as a block? A user has to insert the inserter block, then they have the option to / to trigger the menu? I'd not really expected this to be a block, but rather something built-in to either Editable or the default paragraph block.
|
Superseded by #2630 |
No description provided.