Skip to content
This repository was archived by the owner on Jul 28, 2023. It is now read-only.
This repository was archived by the owner on Jul 28, 2023. It is now read-only.

Nomenclature suggestions #37

@mtias

Description

@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>

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions