En la semana asistí a un Developer Hours dedicado a revisar alternativas a las meta boxes en el editor de bloques de WordPress.
El escenario actual es que las meta boxes se muestran bajo el área del contenido (lo que las hace poco visibles para los usuarios, ya que pueden quedar muy abajo en la pantalla en entradas con mucho contenido) y además impiden la visualización del editor de bloques como iframe (la carga en iframe tiene varias ventajas técnicas).
Además de lo anterior, utilizar meta boxes “clásicos” tiene la gran desventaja de que la edición de esos datos queda “desconectada” del resto del editor de bloques, por lo que no es posible (o al menos mucho más difícil) construir interfaces reactivas.
Por ello, parece existir un consenso en cuanto a que el futuro del editor de bloques seguirá otro rumbo con respecto a la edición de meta datos, ya sea integrándolos en bloques de contenido (lo cual tiene sus propios desafíos) o bien en otras secciones de la interfaz de edición.
Qué opciones existen hoy
Guardar post meta desde un bloque
Esta alternativa implica crear un bloque personalizado, que al editar su información guarda los datos como post meta de la entrada en la que se ha insertado, como se detalla en este tutorial técnico.
Si bien es posible añadir un bloque de forma predeterminada al contenido de una entrada y “bloquear” su eliminación; también es posible desbloquearlo y eliminarlo por completo, por lo que no es muy útil para casos en que el contenido sea tipo ficha con datos requeridos.
Por otra parte, el bloque también se podría utilizar múltiples veces en un mismo contenido, lo cual podría o no ser una ventaja dependiendo del caso de uso.
Panel de opciones del documento
Esta alternativa consiste en utilizar el slotfill PluginDocumentSettingPanel para agregar un panel con los controles de formulario asociados a los metadatos.
Justin Tadlock publicó un tutorial muy completo sobre este tipo de implementación; en el cual se puede ver este video que ejemplifica el modo de interacción:
Este caso se podría ajustar más a los casos en que ciertos metadatos son obligatorios, y permitiría validar su presencia o formato de forma integrada con el editor de bloques.
Como desventaja se presenta el espacio reducido, dado por la ubicación de los controles en el panel lateral, y la posibilidad de que sean ignorados por los usuarios al tener la barra de controles escondida o el panel colapsado.
Controles de formulario en una ventana modal
Esta opción es similar a la anterior, en cuanto a que los controles se podrían integrar de forma explícita en el editor y sería posible validar su presencia y formato, pero utilizando el componente modal que es parte de Gutenberg.
En este caso, el control para abrir la ventana modal se podría insertar dentro del panel lateral, junto a los controles principales del documento (botones de guardar borrador, publicar, etc) u otro de los espacios definidos por la API de slotfills.
El espacio disponible para los controles dependería de la configuración del componente modal, lo que posibilita formularios más complejos, pero igualmente puede ser problemático en cuanto a discoverability en la interfaz de administración.
Opciones a futuro
Una de las opciones que se está contemplando a futuro es destinar las meta boxes a un control de activación próximo a las acciones principales de guardar borrador, publicar, etc:
La discusión sobre esta característica se está desarrollando en este reporte de Github, donde además es posible ver algunas exploraciones sobre la interfaz de administración:
Estos prototipos se pueden ver en los siguientes enlaces de Figma: