Primeros pasos con el desarrollo de bloques de WordPress | trucos CSS

Seamos realistas, desarrollar para WordPress es raro en este momento. Ya sea que sea nuevo en WordPress o lo haya usado durante mucho tiempo, la introducción de las funciones de Edición completa del sitio (FSE), que incluyen editor de bloques (WordPress 5.0) y editor del sitio (WordPress 5.9), han cambiado la forma tradicional en que creamos temas y complementos de WordPress.

Aunque han pasado cinco años desde que nos encontramos por primera vez con el editor de bloques, su desarrollo es difícil porque falta la documentación o está desactualizada. Esto es más una afirmación sobre la rapidez con la que se mueven las características de FSE, algo que Jeff lamentó en una publicación reciente. .

Caso en cuestión: en 2018, se publicó una serie introductoria sobre cómo iniciarse en el desarrollo de Gutenberg aquí mismo en CSS-tricks. Los tiempos han cambiado desde entonces, y aunque este estilo de desarrollo aún funciona, es no es recomendable (además ya create-guten-block el proyecto en el que se basa tampoco es compatible).

En este artículo, tengo la intención de ayudarlo a comenzar con el desarrollo de bloques de WordPress de una manera que siga la metodología actual. Así que sí, las cosas pueden cambiar mucho después de que se publique, pero intentaré centrarme en él de una manera que, con suerte, capture la esencia del desarrollo de bloques, porque aunque las herramientas pueden evolucionar con el tiempo, las ideas básicas probablemente seguirán siendo las mismas.

¿Qué son exactamente los bloques de WordPress?

Comencemos aclarando cierta confusión sobre lo que queremos decir con términos como bloquesTodo el desarrollo que se dedicó a estas características que condujeron a WordPress 5.0 se denominó en código "Gutenberg"- ya sabes, el inventor de imprenta.

Desde entonces, "Gutenberg" se ha utilizado para describir todo lo relacionado con bloques, incluido el editor de bloques y el editor de sitios, por lo que se ha vuelto confuso hasta el punto de que algunas personas depende del nombrePara colmo hay Complemento de Gutenberg donde se prueban las características experimentales para su posible inclusión. Y si cree que llamarlo todo "Edición completa del sitio" resolverá el problema, también hay preocupaciones sobre eso.

Entonces, cuando hablamos de "bloques" en este artículo, nos referimos a los componentes de creación de contenido en el editor de bloques de WordPress. Los bloques se insertan en una página o publicación y brindan la estructura para un tipo específico de contenido. WordPress incluye varios de los bloques "principales" para tipos de contenido comunes como párrafo, lista, imagen, video y audio, para nombrar unos pocos.

Además de estos bloques básicos, también podemos crear bloques personalizados, este es el propósito del desarrollo de bloques en WordPress (también hay filtrado de bloques básicos para modificar su funcionalidad, pero probablemente aún no lo necesites).

¿Qué hacen los bloques?

Antes de sumergirnos en la creación de bloques, primero debemos comprender cómo funcionan internamente los bloques. Esto definitivamente nos ahorrará mucha frustración más adelante.

La forma en que me gusta pensar en un bloque es bastante abstracta: para mí, un bloque es un objeto con algunas propiedades (llamadas atributos) que representa algún contenido. Sé que esto suena bastante vago, pero quédate conmigo. Un bloque se manifiesta principalmente de dos formas: como una interfaz gráfica en el editor de bloques o como un dato en la base de datos.

Cuando abre el editor de bloques de WordPress e inserta un bloque, digamos un bloque Pullquote, obtiene una interfaz agradable. Puede hacer clic en esta interfaz y editar el texto citado. El panel de configuración en el lado derecho de la interfaz de usuario del editor de bloques proporciona opciones para ajustar el texto y ajustar la apariencia del bloque.

Cuando terminas de crear tu cita elegante y presionas publicar, la publicación completa se almacena en la base de datos en wp_posts mesa. Esto no es nuevo debido a Gutenberg. Así es como siempre han funcionado las cosas: WordPress almacena el contenido publicado en una tabla específica en la base de datos. Pero lo nuevo es que Introduciendo el bloque Pullquote forma parte del contenido que se almacena en el post_content campo de wp_posts mesa.

¿Cómo es esta actuación? Mirar:

<!-- wp:pullquote {"textAlign":"right"} -->
<figure class="wp-block-pullquote has-text-align-right">
  <blockquote>
    <p>It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.</p>
    <cite>The Encyclopedia of world peas</cite>
  </blockquote>
</figure>
<!-- /wp:pullquote -->

Parece HTML simple, ¿verdad? Este es técnicamente el bloque "serializado". Observe los datos JSON en el comentario HTML, "textAlign": "right"Está atributo - propiedad asociada al bloque.

Suponga que cierra el Editor de bloques y después de un tiempo lo vuelve a abrir. El contenido del correspondiente post_content el campo se recupera del editor de bloques. Luego, el editor analiza el contenido extraído y dondequiera que encuentre esto:

<!-- wp:pullquote {"textAlign":"right"} -->...<!-- /wp:pullquote -->

... se dice a sí mismo voz:

Ok, esto me parece un bloque de Pullquote. Um... también hay un atributo... Tengo un archivo JavaScript que me dice cómo construir la GUI para un bloque Pullquote en el editor a partir de sus atributos. Tengo que hacerlo ahora para renderizar este bloque en todo su esplendor.

Como desarrollador de bloques, su trabajo es:

1. Dígale a WordPress que desea registrar un tipo específico de bloque con los mismos detalles.
2. Proporcione al editor de bloques el archivo JavaScript que lo ayudará a representar el bloque en el editor mientras lo "serializa" para guardarlo en la base de datos.
3. Proporcione cualquier recurso adicional que el bloque necesite para su correcto funcionamiento, p. estilos y fuentes.

Una cosa a tener en cuenta es que toda esta conversión de datos serializados a GUI, y viceversa, se realiza solo en el editor de bloques. En la parte delantera, el contenido se muestra exactamente como está almacenado. Entonces, en cierto sentido, los bloques son una forma fantástica de colocar datos en la base de datos.

Espero que esto te dé algo de claridad sobre cómo funciona el bloque.

Los bloques son solo complementos

Los bloques son solo complementos. Bueno, técnicamente, tú yo puedo pon bloques en los temas y tu yo puedo colocar varios bloques en un complemento. Pero la mayoría de las veces, si quieres hacer un bloque, vas a hacer un complemento. Entonces, si alguna vez creó un complemento de WordPress, entonces ya está a medio camino de familiarizarse con la creación de un bloque de WordPress.

Pero supongamos por un momento que nunca ha configurado un complemento de WordPress, y mucho menos un bloque, ¿por dónde empieza?

crear un bloque

Miramos qué son los bloques. Comencemos a configurar las cosas para hacer uno.

Asegúrate de tener Node instalado

Esto le dará acceso a npm y npx comandos, donde npm instala las dependencias de su bloque y ayuda a compilar cosas mientras npx ejecutar los comandos del paquete sin instalarlos. Si está en macOS, probablemente ya tenga Node y pueda usarlo nvm para actualizar versiones. Si está en Windows, deberá descargar e instalar nodo.

Crear una carpeta de proyecto

Ahora puede encontrar otros tutoriales que saltan directamente a la línea de comando y le indican que instale un paquete llamado @wordpress/create-blockEste paquete es excelente porque descarga una carpeta de proyecto completamente formada con todas las dependencias y herramientas que necesita para comenzar a desarrollar.

Personalmente, sigo esta ruta cuando configuro mis propios bloques, pero tenga paciencia conmigo por un momento porque quiero eliminar las cosas dudosas que presenta y concentrarme solo en las partes necesarias para comprender el entorno de desarrollo base.

Estos son los archivos que me gustaría mencionar específicamente:

• readme.txt: Esta es una especie de interfaz del directorio de complementos, generalmente se usa para describir el complemento y proporcionar detalles adicionales sobre el uso y la instalación. Si envías tu bloque a Directorio de complementos de WordPresseste archivo ayuda a llenar la página del complemento. Si planea crear un repositorio de GitHub para su complemento de cadena de bloques, entonces también puede considerar README.md archivo con la misma información para que se muestre bien allí.
• package.json: Esto define los paquetes de Nodo que se requieren para el desarrollo. Lo abriremos cuando lleguemos a la instalación. En el desarrollo clásico de complementos de WordPress, puede estar acostumbrado a trabajar con Composer y composer.json Este es el equivalente de eso.
• plugin.php: Este es el archivo del complemento principal y, sí, ¡es PHP clásico! Pondremos el encabezado y los metadatos del complemento aquí y los usaremos para registrar el complemento.

Además de estos archivos, también hay src directorio que debe contener el código fuente de nuestro bloque.

Tener estos archivos y src El directorio es todo lo que necesita para comenzar. Fuera de este grupo, observe esto técnicamente solo necesitamos un archivo (plugin.php) para hacer el complemento. El resto proporciona información o se utiliza para gestionar el entorno de desarrollo.

Lo antes mencionado @wordpress/create-block El paquete crea andamios para estos archivos (y más). Puede pensar en ello como una herramienta de automatización en lugar de una necesidad. De todos modos, hace que el trabajo sea más fácil, por lo que puede permitirse andamiar un bloque con él ejecutando:

npx @wordpress/create-block

Instalación de dependencias de bloque

Suponiendo que tiene listos los tres archivos mencionados en la sección anterior, es hora de instalar las dependencias. Primero, necesitamos especificar las dependencias que necesitaremos. Hacemos esto editando las dependencias. package.jsonDurante el uso @wordpress/create-block utilidad, se genera lo siguiente para nosotros (comentarios agregados; JSON no admite comentarios, así que elimine los comentarios si copia el código):

{
  // Defines the name of the project
  "name": "block-example",
  // Sets the project version number using semantic versioning
  "version": "0.1.0",
  // A brief description of the project
  "description": "Example block scaffolded with Create Block tool.",
  // You could replace this with yourself
  "author": "The WordPress Contributors",
  // Standard licensing information
  "license": "GPL-2.0-or-later",
  // Defines the main JavaScript file
  "main": "build/index.js",
  // Everything we need for building and compiling the plugin during development
  "scripts": {
    "build": "wp-scripts build",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "packages-update": "wp-scripts packages-update",
    "plugin-zip": "wp-scripts plugin-zip",
    "start": "wp-scripts start"
  },
  // Defines which version of the scripts packages are used (24.1.0 at time of writing)
  // https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
  "devDependencies": {
    "@wordpress/scripts": "^24.1.0"
  }
}

{
  "name": "block-example",
  "version": "0.1.0",
  "description": "Example block scaffolded with Create Block tool.",
  "author": "The WordPress Contributors",
  "license": "GPL-2.0-or-later",
  "main": "build/index.js",
  "scripts": {
    "build": "wp-scripts build",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "packages-update": "wp-scripts packages-update",
    "plugin-zip": "wp-scripts plugin-zip",
    "start": "wp-scripts start"
  },
  "devDependencies": {
    "@wordpress/scripts": "^24.1.0"
  }
}

los @wordpress/scripts El paquete es la dependencia principal aquí. Como puedes ver, este es un devDependency lo que significa que ayuda al desarrollo. ¿Cómo es eso? El expone a wp-scripts archivo binario que podemos usar para compilar nuestro código, desde src directorio a build directorio, entre otras cosas.

Hay una serie de otros paquetes que admite WordPress para diferentes propósitos @wordpress/components paquete proporciona varias estructuras prefabricadas interfaz de usuario componentes para el editor de bloques de WordPress, que se puede usar para crear experiencias de usuario consistentes para su bloque que se adhiere a los estándares de diseño de WordPress.

realmente no deber para instalar estos paquetes incluso si desea utilizarlos. Esto se debe a que estos @wordpress las dependencias no están empaquetadas con su código de bloque. En cambio, todos import declaraciones que hacen referencia al código de los paquetes auxiliares, como @wordpress/components — se utilizan para construir un archivo de "activos" en tiempo de compilación. Además, estas declaraciones de importación se convierten en declaraciones que asignan la importación a las propiedades de un objeto global. Por ejemplo, import { __ } from "@wordpress/i18n" se convierte en una versión reducida de const __ = window.wp.i18n.__.(window.wp.i18n como un objeto que está garantizado para estar disponible en el ámbito global una vez que el correspondiente i18n el archivo del paquete está en cola).

Al registrar un bloque en el archivo del complemento, el archivo de "activos" se usa implícitamente para decirle a WordPress las dependencias del paquete para el bloque. Estas dependencias se ponen en cola automáticamente. Todo esto se soluciona detrás de escena, siempre que use scripts Dicho esto, aún puede elegir instalar dependencias de finalización de código e información de parámetros localmente en su package.json expediente:

// etc.
"devDependencies": {
  "@wordpress/scripts": "^24.1.0"
},
"dependencies": {
  "@wordpress/components": "^19.17.0"
}

Ahora que package.json está configurado, deberíamos poder instalar todas estas dependencias yendo a la carpeta del proyecto en la línea de comando y ejecutando npm install.

Si proviene del desarrollo clásico de complementos de WordPress, probablemente sepa que todos los complementos tienen un bloque de información en el archivo principal del complemento que ayuda a WordPress a reconocer el complemento y mostrar información sobre él en la pantalla de complementos del administrador de WordPress.

esto es lo que @wordpress/create-block generado para mí para un complemento llamado creativamente "Hello World":

<?php
/**
 * Plugin Name:       Block Example
 * Description:       Example block scaffolded with Create Block tool.
 * Requires at least: 5.9
 * Requires PHP:      7.0
 * Version:           0.1.0
 * Author:            The WordPress Contributors
 * License:           GPL-2.0-or-later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       css-tricks
 *
 * @package           create-block
 */

Esto está en el archivo principal del complemento, al que puede llamar como quiera. Podrías llamarlo algo genérico como index.php o plugin.php, create-block el paquete lo llama automáticamente lo que proporcione como nombre del proyecto cuando lo instala. Como llamé a este ejemplo "Ejemplo de bloque", el paquete nos dio block-example.php archivo con todas estas cosas.

Querrás cambiar algunos de los detalles, como convertirte en un autor y todo eso. Y no todo esto es necesario. Si estuviera ejecutando esto desde "cero", entonces podría verse algo más parecido a esto:

<?php
/**
 * Plugin Name:       Block Example
 * Plugin URI:        https://css-tricks.com
 * Description:       An example plugin for learning WordPress block development.
 * Version:           1.0.0
 * Author:            Arjun Singh
 * License:           GPL-2.0-or-later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       css-tricks
 */

No entraré en el propósito exacto de cada línea ya que es un un patrón bien establecido en el Manual de complementos de WordPress.

La estructura del archivo

Ya hemos cubierto los archivos necesarios para nuestro bloque, pero si usa @wordpress/create-blockverá un montón de otros archivos en la carpeta del proyecto.

Esto es lo que hay ahora mismo:

block-example/
├── build
├── node_modules
├── src/
│   ├── block.json
│   ├── edit.js
│   ├── editor.scss
│   ├── index.js
│   ├── save.js
│   └── style.scss
├── .editorconfig
├── .gitignore
├── block-example.php
├── package-lock.json
├── package.json
└── readme.txt

¡Uf, eso es mucho! Vamos a llamar a las cosas nuevas:

• build/: esta carpeta recibió los activos compilados al procesar los archivos para su uso en producción.
• node_modules: Contiene todas las dependencias de desarrollo que hemos instalado en tiempo de ejecución npm install.
• src/: esta carpeta contiene el código fuente del complemento que se compila y se envía a build Repasaremos cada uno de los archivos aquí en un momento.
• .editorconfig: Contiene configuraciones para adaptar su editor de código para la consistencia del código.
• .gitignore: este es un archivo de repositorio estándar que identifica los archivos locales que deben excluirse del seguimiento del control de versiones node_modules definitivamente debería incluirse aquí.
• package-lock.json: Este es un archivo generado automáticamente que contiene, para rastrear, actualizaciones de los paquetes necesarios que hemos instalado con npm install.

Bloqueo de metadatos

quiero profundizar src directorio con usted, pero primero se centrará en un solo archivo: block.jsonsi has usado create-block él ya está ahí para ti; si no, adelante y créalo. WordPress se esfuerza por hacer de esta una forma estándar y canónica de registrar un bloque al proporcionar metadatos que brindan contexto para que WordPress reconozca el bloque y lo represente en el Editor de bloques.

esto es lo que @wordpress/create-block generado para mí:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "create-block/block example",
  "version": "0.1.0",
  "title": "Block Example",
  "category": "widgets",
  "icon": "smiley",
  "description": "Example block scaffolded with Create Block tool.",
  "supports": {
    "html": false
  },
  "textdomain": "css-tricks",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css"
}

En realidad hay un un montón de información diferente podríamos incluir aquí, pero todo lo que realmente se requiere es name y titleUna versión súper mínima podría verse así:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "css-tricks/block-example",
  "version": "1.0.0",
  "title": "Block Example",
  "category": "text",
  "icon": "format-quote",
  "editorScript": "file:./index.js",
}

• $schema define el formato del esquema utilizado para validar el contenido del archivo. Parece imprescindible, pero es completamente opcional, ya que permite que los editores de código compatibles verifiquen la sintaxis y proporcionen otras capacidades adicionales, como información sobre herramientas y finalización automática.
• apiVersion se refiere a qué versión de bloqueo de API utiliza el complemento. Hoy es la versión 2 lo último.
• name es una cadena única requerida que ayuda a identificar el complemento. Tenga en cuenta que antepuse esto con css-tricks/ que uso como espacio de nombres para evitar conflictos con otros complementos que pueden tener el mismo nombre. En su lugar, puede elegir usar algo como sus iniciales (p. ej. as/block-example).
• version es algo WordPress sugiere usar como un mecanismo para eliminar el caché cuando se lanzan nuevas versiones.
• title es el otro campo obligatorio y establece el nombre que se usa en todas partes donde se muestra el complemento.
• category agrupa el bloque con otros bloques y los muestra juntos en el editor de bloques Las categorías existentes actuales incluyen text, media, design, widgets, themey embede incluso puedes crear categorías de usuarios.
• icon te permite elegir algo de biblioteca de dashicons para una representación visual de su bloque en el editor de bloques. yo suelo format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) ya que en este ejemplo hacemos nuestra propia cosa pullquote. Es bueno que podamos usar íconos existentes en lugar de tener que crear los nuestros, aunque eso es ciertamente posible.
• editorScript es donde se encuentra el archivo JavaScript principal, index.jsvive

Registrar el bloque

Una última cosa antes de llegar al código real y es registrar el complemento. Acabamos de configurar todos estos metadatos y necesitamos una forma de que WordPress los use. De esta manera, WordPress sabe dónde encontrar todos los activos del complemento para que puedan ponerse en cola para su uso en el editor de bloques.

Registrar el bloque es un proceso dual. Necesitamos registrarlo tanto en PHP como en JavaScript. Para el lado de PHP, abra el archivo del complemento principal (block-example.php en este caso) y agregue lo siguiente inmediatamente después del encabezado del complemento:

function create_block_block_example_block_init() {
  register_block_type( __DIR__ . '/build' );
}
add_action( 'init', 'create_block_block_example_block_init' );

Esto es lo que create-block utilidad generada para mí, por lo que la función se nombra de la manera que es. Podemos usar un nombre diferente. Nuevamente, la clave es evitar conflictos con otros complementos, por lo que es una buena idea usar su espacio de nombres aquí para que sea lo más único posible:

function css_tricks_block_example_block_init() {
  register_block_type( __DIR__ . '/build' );
}
add_action( 'init', 'css_tricks_block_example_block_init' );

Por qué indicamos build directorio si block.json con todos los metadatos del bloque srcEsto se debe a que nuestro código aún debe compilarse. scripts paquete procesa el código de los archivos en src directorio y coloca los archivos compilados utilizados en la producción del build directorio mientras que también copia de block.json expediente en el proceso.

Bien, pasemos al lado de JavaScript para registrar el bloque. Abrir src/index.js y asegúrate de que se vea así:

import { registerBlockType } from "@wordpress/blocks";

import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";

const { name } = metadata;

registerBlockType(name, {
  edit: Edit,
  save: Save,
});

¡Estamos entrando en la tierra de React y JSX! Esto le dice a WordPress que:

• Importar registerBlockType módulo de @wordpress/blocks paquete.
• Importar metadatos de block.json.
• Importar Edit y Save componentes de sus respectivos archivos. Pondremos el código en estos archivos más tarde.
• Registre el bloque y use Edit y Save componentes para renderizar el bloque y guardar su contenido en la base de datos.

que esta pasando con edit y save Uno de los matices del desarrollo de bloques en WordPress es distinguir el "backend" del "frontend", y estas funciones se utilizan para representar el contenido del bloque en aquellos contextos en los que edit controla el renderizado en el backend y save guarda el contenido del editor de bloques en la base de datos para representar el contenido en la parte frontal del sitio.

Examen rápido

Podemos trabajar un poco para ver cómo funciona nuestro bloque en el editor de bloques y cómo se representa en la interfaz. Vamos a abrir index.js otra vez y uso edit y save Las funciones devuelven un cuerpo de contenido que ilustra cómo funcionan:

import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";

const { name } = metadata;

registerBlockType(name, {
  edit: () => {
    return (
      "Hello from the Block Editor"
    );
  },
  save: () => {
    return (
      "Hello from the front end"
    );
  }
});

Esta es básicamente una versión simplificada del mismo código que teníamos antes, excepto que apuntamos directamente a los metadatos en el block.json para recuperar el nombre del bloque y omitido Edit y Save componentes a medida que implementamos las funciones directamente desde aquí.

Podemos compilar esto ejecutando npm run build en la línea de comando Luego tenemos acceso a un bloque llamado "Ejemplo de bloque" en el editor de bloques:

Si soltamos el bloque en el área de contenido, obtenemos el mensaje que devolvimos edit función:

Si guardamos y publicamos la publicación, deberíamos recibir el mensaje del que regresamos save característica cuando se mira desde el frente:

crear un bloque

¡Parece que todo está conectado! Podemos volver a lo que teníamos index.js antes de la prueba ahora que hemos confirmado que todo funciona:

import { registerBlockType } from "@wordpress/blocks";

import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";

const { name } = metadata;

registerBlockType(name, {
  edit: Edit,
  save: Save,
});

Darse cuenta de edit y save funciones están vinculadas a dos archivos existentes en el src directorio que @wordpress/create-block generado para nosotros e incluye cualquier importación adicional que necesitemos en cada archivo. Sin embargo, lo más importante es que estos archivos establecen Edit y Save componentes que contienen el marcado de bloque.

Marcando el borde de fuga (src/edit.js)

import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";

export default function Edit() {
  return (
    <p {...useBlockProps()}>
      {__("Hello from the Block Editor", "block-example")}
    </p>
  );
}

Ves lo que hicimos allí? Importamos accesorios de @wordpress/block-editor paquete que nos permite generar clases que luego podemos usar para diseñar. tambien importamos __ función de internacionalización, para trabajar con traducciones.

Marcado frontal (src/save.js)

Esto crea un Save componente y usaremos casi lo mismo que src/edit.js con un texto ligeramente diferente:

import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";

export default function Save() {
  return (
    <p {...useBlockProps.save()}>
      {__("Hello from the front end", "block-example")}
    </p>
  );
}

Nuevamente obtenemos una buena clase que podemos usar en nuestro CSS:

Bloques de estilo

Acabamos de ver cómo usar accesorios de bloque para crear clases. Estás leyendo este artículo en un sitio completamente dedicado a CSS, así que siento que me estaría perdiendo algo si no miramos específicamente cómo escribir estilos de bloque.

Distinción entre estilos anterior y posterior

Si miras block.json en src directorio encontrará dos campos relacionados con los estilos:

• editorStyle proporciona la ruta a los estilos aplicados al back-end.
• style es la ruta para los estilos compartidos que se aplican tanto al frontend como al backend.

Kev Quirk tiene un artículo detallado que muestra su enfoque para hacer que el editor de back-end se vea como la interfaz de usuario de front-end.

Recordar que @wordpress/scripts copia del paquete block.json archivo al procesar el código en el /src directorio y coloca los activos compilados en el /build Está build/block.json archivo que se utiliza para registrar el bloque. Eso significa que cada vez que proporcionamos src/block.json debe escribirse contra build/block.json.

Usando Sass

Podemos colocar algunos archivos CSS en el build directorio, especifique las rutas en src/block.jsonejecutar la compilación y condenarla. Pero no usa todo el poder de @wordpress/scripts proceso de compilación que puede compilar Sass a CSS. En su lugar, colocamos nuestros archivos de estilo en el src e importarlos a JavaScript.

Al hacer esto, debemos tener en cuenta cómo @wordpress/scripts estilos de proceso:

• Nombre del archivo style.css o style.scss o style.sassimportado en código JavaScript se compila para style-index.css.
• Todos los demás archivos de estilo se compilan y fusionan en el index.css.

los @wordpress/scripts usando paquetes paquete web agrupar y @wordpress/scripts usos Complemento PostCSS para trabajar con estilos de procesamiento. PostCSS se puede ampliar con complementos adicionales scripts El paquete usa aquellos para Sass, SCSS y Autoprefixer, todos los cuales están disponibles para usar sin instalar paquetes adicionales.

De hecho, cuando rotas tu bloque inicial con @wordpress/create-blockobtiene una buena ventaja con los archivos SCSS que puede usar para comenzar:

• editor.scss contiene todos los estilos que se aplican al editor de back-end.
• style.scss contiene todos los estilos compartidos por el frontend y el backend.

Ahora veamos este enfoque en acción escribiendo algo de Sass que compilaremos en CSS para nuestro bloque. Aunque los ejemplos no serán muy atrevidos, todavía los estoy escribiendo en los archivos SCSS para demostrar el proceso de compilación.

Al frente y estilos de fondo

Bien, comencemos con los estilos que se aplican tanto al front-end como al back-end. Primero tenemos que crear src/style.scss (ya está ahí si usas @wordpress/create-block) y nos aseguramos de importarlo, lo cual podemos hacer en el index.js:

import "./style.scss";

Abrelo src/style.scss y suelte algunos estilos básicos allí usando la clase que los accesorios de bloque generaron para nosotros:

.wp-block-css-tricks-block-example {
  background-color: rebeccapurple;
  border-radius: 4px;
  color: white;
  font-size: 24px;
}

¡Eso es todo por ahora! Cuando ejecutamos la compilación, esto se compila en el build/style.css y está especificado tanto por el editor de bloques como por el front-end.

estilos de fondo

Es posible que deba escribir estilos que sean específicos del editor de bloques. Para hacer esto, cree src/editor.scss (otra vez, @wordpress/create-block hace eso por ti) y coloca algunos estilos allí:

.wp-block-css-tricks-block-example {
  background-color: tomato;
  color: black;
}

Luego importarlo edit.jscual es el archivo que contiene nuestro Edit componente (podemos importarlo donde queramos, pero dado que estos estilos son para el editor, tiene más sentido importar el componente aquí):

import "./editor.scss";

Ahora que estamos corriendo npm run buildlos estilos se aplican al bloque en ambos contextos:

Estilos de referencia en block.json

Importamos los archivos de estilo en el edit.js y index.jspero recuerde que el paso de compilación genera dos archivos CSS para nosotros en el build directorio: index.css y style-index.css Necesitamos especificar estos archivos generados en los metadatos del bloque.

Agreguemos algunas declaraciones a block.json metadatos:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "css-tricks/block-example",
  "version": "1.0.0",
  "title": "Block Example",
  "category": "text",
  "icon": "format-quote",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css"
}

Correr npm run build una vez más, instale y active el complemento en su sitio de WordPress y ¡ya está listo para usarlo!

Puedes usar npm run start para ejecutar su compilación en modo reloj, compilando automáticamente su código cada vez que realiza un cambio en su código y lo guarda.

Nosotros estamos arañando la superficie

Los bloques reales utilizan la barra lateral de configuración del editor de bloques y otras características que proporciona WordPress para crear experiencias de usuario ricas.Además, el hecho de que hay esencialmente dos versiones de nuestro bloque: edit y save — también debe pensar en cómo organiza su código para evitar la duplicación de código.

Pero esperamos que esto ayude a desmitificar el proceso general de creación de bloques de WordPress. Esta es realmente una nueva era en el desarrollo de WordPress. Es difícil aprender nuevas formas de hacer las cosas, pero tengo muchas ganas de ver cómo se desarrolla. Herramientas como @wordpress/create-block ayuda, pero incluso entonces es bueno saber exactamente lo que está haciendo y por qué.

¿Cambiarán las cosas que hemos cubierto aquí? ¡Más probable! Pero al menos tiene una línea de base para trabajar a medida que continuamos viendo cómo maduran los bloques de WordPress, incluidas las mejores prácticas para crearlos.

Referencias

Una vez más, mi objetivo aquí es trazar un camino eficiente para entrar en el desarrollo de bloques en esta temporada cuando las cosas se mueven rápido y la documentación de WordPress no tiene problemas para ponerse al día. Aquí hay algunos recursos que usé para armar esto: