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.

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:

/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 👍

I really like this approach using a HOC.

Agreed 😃

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.