Introducing Gutenberg Fields Middleware

We’re happy to formally announce rtCamp’s Gutenberg Fields Middleware project, our exploration of what a declarative fields API for Gutenberg blocks might look like and what sort of value it could provide. Thanks to rtCampers Sayed, Yahil, and Vaishali for their work on this initial prototype release.

Haven’t written a Gutenberg block yet? During the month of April, we’re offering complimentary technical introductions to Gutenberg as a public service campaign for the community.

Once you’re acquainted with Gutenberg blocks, experimenting with the Gutenberg Fields Middleware is simply a matter of installing the project as a WordPress plugin and declaring gutenberg-fields-middleware as a script dependency. Fields are then registered as attribute configuration.

Here’s how you might register url, text, and range fields:

registerBlockType( 'example-namespace/example-block', {
    title: 'Example Block',
    attributes: {
        url: {
            type: 'string',
            field: {
                type: 'url',
            },
        },
        text: {
            type: 'string',
            field: {
                type: 'text',
                placeholder: 'Enter link text',
            },
        },
        range: {
            type: 'string',
            field: {
                type: 'range',
                label: __( 'Columns' ),
                placement: 'inspector',
            },
        },
    },

    edit( props, middleware ) {
        return [
            middleware.inspectorControls,
            middleware.fields.url,
            middleware.fields.text,
            middleware.fields.range,
        ];
    },
});

We want your feedback! Reach out with questions, suggestions, pull requests and bug reports in the project GitHub repository.

Links: Gutenberg Fields Middleware Project on GitHub | Schedule a Technical Introduction to Gutenberg

2 responses to “Introducing Gutenberg Fields Middleware”

  1. If this was moved to the server instead of the client, we’d really be in business. . .The REST API (and WPGraphQL, etc) could expose data about registered blocks. . . then external clients (iOS, Android, Calypso, etc) could fetch the registry and have enough info to render a UI to interact with blocks as well.

    I think writing custom / any JS to register blocks should be an edge case, not the norm. The more custom JS we have to write, the less external systems can interact with blocks.

  2. Ha! Looking at the Github repo, looks like you beat me to it. . .Server Side Block registration. Awesome.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.