Add reusable blocks to the block autocompleter #4769

noisysocks · 2018-01-31T04:41:40Z

Would fix #4769 and fix #4225.

Proof of concept of the third approach listed in #3791 (comment).

Pulls <Autocomplete> out of the paragraph block and implements block autocompletion via a BlockEdit filter.

By defining the filter in the editor module, we can easily add reusable blocks into the autocompleter since we can access to the editor Redux state.

cc. @aduth @youknowriad

noisysocks · 2018-01-31T04:45:13Z

editor/hooks/autocomplete/index.js

+		return (
+			<Autocomplete completers={ [ blockAutocompleter( { items, onReplace } ), userAutocompleter() ] }>
+				{ ( { isExpanded, listBoxId, activeId } ) => (
+					// TODO: These aria attributes probably belong on the <Editable>... not sure how to make that happen


This is the only problem I ran into. Not sure where these aria attributes which were previously on the <Editable> should go.

Yes, I agree that they fit better here than as part of <Editable />. I think @afercia might be better suited to answer this question.

gziolo · 2018-02-01T08:28:11Z

editor/hooks/autocomplete/index.js

+		const { name, items, onReplace } = props;
+
+		// Only wrap paragraph blocks with <Autocomplete>
+		if ( name !== 'core/paragraph' ) {


It makes a lot of sense for blockAutocompleter to be applied to a paragraph block only, but not sure if we want to keep this limitation for userAutocompleter, too.

We could make it more customizable by using supports proprty from the block definition. One way of doing it would be:

name: 'core/paragraph', supports: { autocompleters: [ 'block', 'user' ] },

name: 'core/list', supports: { autocompleters: [ 'user' ] },

This is an interesting idea, @gziolo. It's better to declare autocompleters explicitly than to bury them in block implementation.

Would it be better to provide the actual completers instead of strings? Do we gain anything from the indirection of using strings?

If we specify an actual list of completers, we could override aspects of them using the blocks.registerBlockType filter rather than the dedicated filter discussed by #4609. The initial filters I proposed there were too granular for a first pass, but maybe using blocks.registerBlockType for this isn't granular enough. :)

Would it be better to provide the actual completers instead of strings? Do we gain anything from the indirection of using strings?

Yes, this is also an option to define them as part of the block API. I like how this discussion goes. Very good ideas :)

We do something similar with transformers. See here:

gutenberg/blocks/library/code/index.js

Line 37 in 727da2c

transforms: {

It might be a way to go in this case, too. You wouldn't have to create new hooks, you could use blocks.registerBlockType as described here.

/cc @aduth @youknowriad

Having to add autocompleters more broadly was one of the initial reasons for the refactoring of these autocompleters. so yes 💯

I like thesupportsAPI thought as it can be easily moved to the backend for instance and I see other blocks using the "block" autocompleter as well (for example heading).

Edit: The problem about the supports API (or any generic API) is that it assumes that it would work regardless of the block implementation. I'm not certain it's the case. What about blocks with multiple RichText components or without any input/textarea/richtext? How will this behave in that case?

If I comment out this check then it seems to work OK with blocks that have multiple RichText components:

And it doesn't seem to affect blocks that use <input>s and <textarea>s:

So I think it would be reasonable to to have all blocks wrapped with the user autocompleter and only paragraph blocks wrapped with the block autocompleter.

So I think it would be reasonable to to have all blocks wrapped with the user autocompleter and only paragraph blocks wrapped with the block autocompleter.

Interesting approach. I like the idea of having more specialized HOCs 👍

brandonpayton · 2018-02-01T22:57:31Z

editor/hooks/autocomplete/index.js

+import { blockAutocompleter, userAutocompleter } from './autocompleters';
+import { getInserterItems } from '../../store/selectors';
+
+function withAutocomplete( BlockEdit ) {


I really like this approach using a HOC.

Agreed 😃

brandonpayton · 2018-02-01T23:18:16Z

editor/hooks/autocomplete/index.js

+			enabledBlockTypes: settings.blockTypes,
+		} ) ),
+		connect( ( state, ownProps ) => ( {
+			items: getInserterItems( state, ownProps.enabledBlockTypes ),


As part of integrating Gutenberg into Automattic P2's, we need to use a different data source for the users autocompleter because we allow pinging any Automattician, not just users who are a member of a particular P2. I'm not too familiar with how data dependencies are satisfied within Gutenberg (except my perception is that there are a number of approaches and that withApiData is preferred for the future). Do you see a good way for us to override the request and provision of completion data?

I didn't read well enough :). I see now that only blockAutocompleter is initialized with a list of items. Other completers like the userAutocompleter could source their own data if they want.

Pulls <Autocomplete> out of the paragraph block and implements block autocompletion via a BlockEdit filter. By adding the filter in the `editor` module, we can easily add reusable blocks into the autocompletion since we have access to editor's Redux state.

noisysocks · 2018-03-06T04:43:46Z

Closing due to staleness. Will revisit this soon.

noisysocks added the [Status] In Progress Tracking issues with work in progress label Jan 31, 2018

noisysocks mentioned this pull request Jan 31, 2018

Reusable Blocks: Display reusable blocks in Autocompleter #3791

Closed

noisysocks commented Jan 31, 2018

View reviewed changes

noisysocks mentioned this pull request Feb 1, 2018

Inserter: Restrict unallowed block types more broadly #4097

Closed

gziolo reviewed Feb 1, 2018

View reviewed changes

gziolo mentioned this pull request Feb 1, 2018

Declare and override autocompleters via filter #4609

Merged

3 tasks

gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Feb 1, 2018

gziolo requested review from youknowriad and aduth February 1, 2018 08:45

brandonpayton reviewed Feb 1, 2018

View reviewed changes

noisysocks force-pushed the try/add-reusable-blocks-to-autocompleter branch from 11bf8ff to e576267 Compare February 2, 2018 01:06

aduth added the [Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) label Feb 28, 2018

noisysocks closed this Mar 6, 2018

noisysocks deleted the try/add-reusable-blocks-to-autocompleter branch March 6, 2018 04:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add reusable blocks to the block autocompleter #4769

Add reusable blocks to the block autocompleter #4769

noisysocks commented Jan 31, 2018 •

edited

Loading

noisysocks Jan 31, 2018

gziolo Feb 1, 2018

gziolo Feb 1, 2018

brandonpayton Feb 1, 2018

gziolo Feb 2, 2018 •

edited

Loading

gziolo Feb 2, 2018

youknowriad Feb 2, 2018 •

edited

Loading

noisysocks Feb 5, 2018

gziolo Feb 5, 2018

brandonpayton Feb 1, 2018

gziolo Feb 1, 2018

brandonpayton Feb 1, 2018

brandonpayton Feb 1, 2018

noisysocks commented Mar 6, 2018

Add reusable blocks to the block autocompleter #4769

Add reusable blocks to the block autocompleter #4769

Conversation

noisysocks commented Jan 31, 2018 • edited Loading

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

gziolo Feb 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad Feb 2, 2018 • edited Loading

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

noisysocks commented Mar 6, 2018

noisysocks commented Jan 31, 2018 •

edited

Loading

gziolo Feb 2, 2018 •

edited

Loading

youknowriad Feb 2, 2018 •

edited

Loading