Nomenclature suggestions

[mtias]

Great to see all the explorations and progress. Even though nothing is finalized yet, it seems timely to look at the API surface and some of the naming conventions to ensure we are putting forward the best possible set of tools.

Can we consider whether View is a better nomenclature to use than Frontend?

registerBlockType( 'block-name', {
	edit: Edit,
	// The Save component is derived from the View component.
	view: View,
} );

and

import View from './view';
registerBlockType( 'block-name', View );

---

Registration

// Before
class GutenbergBlock extends HTMLElement {}

// After
class WpBlock extends HTMLElement {}

Same goes for other APIs like events and attributes:

// Before
new CustomEvent( 'gutenberg-context', {} )

// After
new CustomEvent( 'block-context', {} )
// or
new CustomEvent( 'wp-block-context', {} )

Similarly data- attributes should use block or wp-block instead of gutenberg namespace.

---

Custom Elements

Super interesting to see the use of custom elements, I think it's a good path forward. I'd suggest improving the names as well:

<!-- before -->
<gutenberg-interactive-block>

<!-- after -->
<wp-block>

Can we assume interactivity if it's declared as a custom element?

<!-- before -->
<gutenberg-inner-blocks>

<!-- after -->
<wp-inner-blocks>

[luisherranz]

Hey Matías, thanks for chiming in because, as far as I know, most of the contributors collaborating here are not familiar with Gutenberg nomenclature yet (me the first!), so the sooner we learn about it, the better 🙂

Can we consider whether View is a better nomenclature to use than Frontend

Sure. I used the frontend name because there is a possibility that we want to differentiate between the current view script enqueuing behavior, which is always enqueued, and an enqueuing that is deferred in time based on the different hydration technique, which may need a different name. But it's not even clear if we won't be able to do so with backward compatibility with view, so I agree to keep the view name for now. We'll make a PR to change it 🙂

wp-block vs block- instead of gutenberg-

This has been more of a surprise to me.

So it looks like Gutenberg is only the project name, but none of the APIs should have the Gutenberg name. Is that correct?

On the other hand, now that Gutenberg is being adopted outside of WordPress (Drupal, Tumblr, Laravel...), using wp- feels a bit weird to me.

Should we try to use a generic block- name then? It looks nice and clean, but it feels a bit riskier because both the event and the custom element namespaces are public.

<interactive-block>
<inner-blocks>

new CustomEvent( 'block-context', {} )

And what do you think about wp-? Is it ok to use, even if Gutenberg is used outside of WordPress?
(Maybe as a reminder that Gutenberg is still a WordPress initiative 😄)

---

For what is worth, if I had to vote right now, I think I'd go with the generic names.

[mtias]

I recall the wp- prefix was configurable at some point, at least for block parsing + serialization, but it's also hardcoded in many classes, docs, etc. I'm fine trying the generic block name first, though I don't like interactive-block :)

[luisherranz]

I recall the wp- prefix was configurable at some point

Oh, that's a good idea if a prefix is unavoidable. However, I'd use it with care because it could cause extensibility problems (generic code that needs to target wp-block, drupal-block, xxx-block…).

though I don't like interactive-block :)

It's true that we could end up using it for non-interactive blocks (maybe to store things like static Block Context) and it's not part of the block itself, so what about block-root?

<block-root>
  <div>my block...</div>
</block-root>

[mtias]

wp-block seems better than block-root :)

[luisherranz]

I've opened a PR to make these changes.

I'm still not convinced with the wp- prefix coupling, though 🙂