Ich bin gerade im Urlaub und hatte ein paar technikfreie Tage, daher kommt mein Blog-Beitrag diese Woche ein wenig später. In meinem vorherigen Beitrag habe ich euch gezeigt, wie ihr einen Block ohne ES6/React Code schreiben könnt. Diese Woche möchte ich euch nun zeigen, was ihr mindestens tun müsste, um das volle Potenzial aus der modernen JavaScript-Entwicklung zu holen, ohne dabei zu komplex zu werden.

Erstellen eines Blocks mit dem „create-block“ Skript

Wie ich bereits im letzten Beitrag erwähnt hatte, würde ich euch sehr stark empfehlen, euch das create-block Paket anzusehen, mit dem ihr ein kleines Plugin erstellen könnt. Es erstellt eine ganz Menge von Dateien, mit denen ihr dann sofort loslegen könnt. Wir erstellen hier nun das gleiche Beispiel wie auch dem letzten Beitrag, indem wir innerhalb des wp-content/plugins Ordners den folgenden Befehl ausführen:

npx @wordpress/create-block random-posts-server-side-render-block-es6

Dies erstellt die folgenden Dateien im neu erstellten Plugin-Ordner:

$ tree
.
├── node_modules
├── package.json
├── random-posts-server-side-render-block-es6.php
├── readme.txt
└── src
    ├── block.json
    ├── edit.js
    ├── editor.scss
    ├── index.js
    ├── save.js
    └── style.scss

Im node_modules Ordner befinden sich alle Dateien, die für die Kompilierung von ES6 Code notwendig ist, damit der Browser diesen ausführen kann. Die package.json Datei definiert alle dazu notwendigen Abhängigkeiten sowie die Befehle, die ausgeführt werden.

Die Block-Definition

Die wichtigste Datei in einem „Block-Plugin“ ist die src/block.json Datei. In dieser werden Name, Titel, Icon und andere Details definiert:

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "rpssrb/random-posts",
    "version": "0.1.0",
    "title": "Random Posts",
    "category": "widgets",
    "icon": "smiley",
    "description": "An example for a ServerSideRender block using minimal ES6 code.",
    "supports": {
        "html": false
    },
    "textdomain": "random-posts-server-side-render-block-es6",
    "editorScript": "file:./index.js",
    "editorStyle": "file:./index.css",
    "style": "file:./style-index.css"
}

Am Ende dieser Datei findet ihr drei sehr nützliche Zeilen. Diese definieren, wo die Asset-Dateien liegen. Während wir also im letzten Beitrag noch wp_enqueue_scripts verwendet haben, um die JavaScript-Datei zu laden, bekommen wir das nun einfach so dazu. Es ist also nicht mehr notwendig in PHP zu prüfen, ob die Datei existiert, diese mit ihren Abhängigkeiten zu laden und einen Timestamp für das Caching anzuhängen. Allein dieses kleine Feature ist es schon wert, dass man sich ein wenig mehr mit moderner Block-Entwicklung beschäftigt.

Ihr könntet nun weiterhin ES5 Code in diese JavaScript-Datei schreiben, aber sehen wir uns doch unser Beispiel mal mit ein wenig modernem JavaScript-Code an.

Registrierung des Server-Side-Rendered-Blocks mit ES6

Wie ihr oben im Auszug des Dateisystems gesehen habt, werden mit dem Skript drei JS Dateien erzeugt. Die index.js Datei registriert den Block. Die edit.js Datei ist zuständig für die Ausgabe des Blocks im Block-Editor, inkl. der Einstellungsoptionen. Die save.js wird abschließend verwendet, um den Block in den Inhalt des Beitrags zu speichern. Diese beiden zusätzlichen Dateien können verwendet werden, aber man kann auch alles in die index.js schreiben. Bei wirklich komplexen Blöcken würde man die Dateien sogar noch mehr aufspalten und beispielsweise die edit.js in kleinere (wiederverwendbare) Teile zerlegen. Aber um es weiterhin möglichst einfach zu halten, verwenden wir nur die index.js Datei:

import ServerSideRender from '@wordpress/server-side-render';
import { registerBlockType } from '@wordpress/blocks';
import './editor.scss';
import './style.scss';
import metadata from './block.json';

registerBlockType(
    metadata.name,
    {
        edit() {
            return (
                <ServerSideRender
                    block="rpssrb/random-posts"
                />
            );
        }
    }
);

Um eine Komponente oder Funktion in ES6 nutzen zu können, müssen wir sie zuerst importieren. Wir werden in dem Beispiel die Komponente ServerSideRender sowie die Funktion registerBlockType einsetzen. Wenn ihr den Code insgesamt mit unserem Beispiel von letzter Woche vergleicht, dann werdet ihr feststellen, dass er gar nicht so anders aussieht. Dieser „komisch aussehende HTML-Tag“ ist JSX, eine Erweiterung für HTML, die von React verwendet wird, um dessen Komponenten zu erstellen. Wenn man an diese Komponenten einen Parameter übergeben möchte, dann verwendet man dazu Attribute, genau wie in HTML (anstatt ein JSON-Objekt zu verwenden, wie in der ES5-Variante). In diesen Attributen kann man auch direkt JavaScript-Code verwenden. Für unsere ServerSideRender Komponente übergeben wir aber nur einen statischen Blocknamen.

Euch ist vielleicht ebenfalls aufgefallen, dass wir den Namen des Blocks für die registerBlockType Funktion aus dem metadata Objekt erhalten, das wir ebenfalls importieren. Das gibt uns die Möglichkeit, auf alle darin deklarierten Werte zuzugreifen. In diesem sehr einfachen Beispiel ist das nur der Name. Wir könnten sogar auch den Wert für das block Attribut der ServerSideRender dynamisch aus den Metadaten setzen, aber wir verwenden hier einen statischen String.

Die zwei Zeilen, die ich bisher noch nicht angesprochen habe, sind die Imports für die SCSS-Dateien. Wenn ihr das @wordpress/scripts Paket verwendet, das mit dem npx Befehl oben installiert wird, dann bekommt ihr eine Sass-Kompilierung einfach mit dazu. Ihr benennt einfach zwei Dateien mit editor.scss und style.scss und diese werden dann automatisch nur für den Block-Editor oder auch für das Frontend kompiliert.

Jetzt, nachdem ihr diesen schönen Code geschrieben habt, könnt ihr ihn endlich kompilieren. Wenn ihr das nur einmal machen wollt (in einer minifizierten Version, vorgesehen für den produktiven Einsatz), dann führt ihr npm run build aus. Während der aktiven Entwicklung verwendet ihr aber eher npm run start, um immer eine aktuelle (ausführliche und somit besser für das Debugging geeignete) Version zu haben, die den Code widerspiegelt, den ihr gerade schreibt.

Registrierung der PHP-Callback-Funktion für den Server-Side-Rendered-Block

Da wir hier noch immer einen Block schreiben, der seinen Inhalt aus dem PHP-Backend bekommt, müssten wir noch immer eine Callback-Funktion registrieren. Das sieht ziemlich ähnlich zu unserem vorherigen Beispiel aus. Allerdings verwenden wir hier die index.js Datei, um den Block in PHP zu registrieren und fügen die Callback-Funktion über die weiteren Parameter hinzu.

function create_block_rpssrb_block_init() {
	register_block_type(
		__DIR__ . '/build',
		[
			'render_callback' => 'rpssrb_render_callback',
		]
	);
}
add_action( 'init', 'create_block_rpssrb_block_init' );

Statt den Blocknamen zu verwenden, geben wir also nur den Pfad zum build Ordner an, der durch das Build-Skript erstellt wird. In diesem Ordner sucht PHP nach einer index.js Datei und darin dann nach dem Namen für den Block.

Wir verwenden auch weiterhin die gleiche Callback-Funktion aus dem vorherigen Beitrag. Auch hier können wir wieder den „Bonus“ haben, um die gleiche Callback-Funktion auch mit einem Shortcode zu verwenden.

Fazit

Es ist nicht wirklich schwer, einen Block mit ES6 Syntax zu schreiben. Wenn man dazu noch das create-block Paket (oder das @wordpress/script Paket) verwendet, wird auch der schwierige Teil für die Kompilierung sehr viel einfacher. Das Einzige, was ihr noch tun müsst – und das etwas schwerer sein kann – ist die Installation von node sowie die anschließende Installation von npm auf eurem System. Aber selbst dann müsst ihr dafür sogar, dann diese beiden immer aktuell und kompatibel mit den Paketen sind, die ihr verwendet. Das kann von Zeit zu Zeit schon etwas nervig sein.

Den Grund für all das werde ich in meinem nächsten Blogbeitrag behandeln, wenn wir ein paar einfache Einstellungsoptionen zum Block hinzufügen, um ihn noch besser nutzbar zu machen.