Pregúntele al cantinero: ¿Qué sucede cuando cambia el marcado de bloque?

Soy un desarrollador que comenzó a desarrollar con Gutenberg recientemente. Hay un montón de increíbles beneficios y características, pero también hay un montón de inconvenientes, inconsistencias, así como una documentación absolutamente horrible y desactualizada.

Uno de los peores aspectos de Gutenberg desde la perspectiva del desarrollador ha sido la validación de bloques. Considere el siguiente escenario. Construyo un bloque personalizado (no dinámico) basado en JavaScript y un editor de CMS agrega el bloque a miles de páginas. ¿Qué sucede cuando o si necesito actualizar el marcado del bloque?

De forma predeterminada, todos los bloques entrarán en un estado de invalidación y no se reflejarán en el front-end del sitio. El editor de CMS tendría que entrar en miles de páginas y hacer clic manualmente en el botón que permite recuperar el bloque.

Se han sugerido las obsolescencias de bloques como una forma de resolver esto, pero la API está mal documentada, es confusa y parece que no se podrá mantener a largo plazo con más de unas pocas obsolescencias.

¿No debería haber una forma para que los desarrolladores de bloques opten por no participar en el proceso de validación o una forma global de recuperar bloques?

PJ

Ciertamente no estás ocultando nada, PJ. Si bien gran parte de esto es un poco más técnico de lo que normalmente me gusta cubrir aquí en Tavern, decidí comunicarme con Riad Benguella, uno de los principales desarrolladores de Gutenberg, para obtener más información sobre la situación.

Antes de sumergirme en su respuesta, he pensado un poco en un aspecto de su pregunta. Hay momentos en los que los desarrolladores necesitan desaprobar el marcado antiguo y pasar a algo nuevo. Sin embargo, esto no debería suceder con frecuencia. En general, es un signo de arquitectura pobre si el HTML necesita ser revisado regularmente. Esto también genera otros problemas, como que un tercero no pueda mantener los cambios de estilo.

Al desarrollar bloques o cualquier tipo de aplicación que genere código front-end, debe pensar en cómo debería verse hoy y dentro de 10 años. ¿Qué sucede si un usuario agrega CSS personalizado para diseñar su bloque y la estructura HTML del bloque ha cambiado? Desde su perspectiva, la actualización de su bloque ha roto su sitio. Lo mismo podría decirse de otro complemento que amplíe su complemento de alguna manera.

Pregúntele a cualquier autor de tema qué tan frustrante es cada vez que Gutenberg/WordPress cambia su salida de bloque. Si bien ha mejorado en los últimos años, diseñar bloques para el editor y el front-end a menudo ha sido una pesadilla de mantenimiento.

Como desarrollador, siempre he tratado de pensar en las consecuencias reales de hacer estos cambios desde la perspectiva del usuario. Eso debería suceder desde el día 1, no después de que hayas lanzado tu proyecto.

Hacer esto agrega tiempo al proyecto inicial cuando solo está tratando de sacarlo por la puerta y ponerlo en manos de los usuarios. Aquí es donde ayuda dar un paso atrás antes del lanzamiento. Aléjate de la computadora. Ir a caminar. Piense en la arquitectura de su proyecto y si es ideal a largo plazo.

“Para las actualizaciones/versiones de bloques, es de hecho una de las áreas de las API de Gutenberg donde necesitábamos hacer concesiones arquitectónicas, y decidimos favorecer la experiencia del usuario sobre la del desarrollador”, dijo Benguella.

Independientemente de su método de desarrollo, seguir el enfoque del proyecto de una experiencia de usuario primero ayudará a largo plazo.

“Para entender el problema correctamente, uno necesita entender cómo funcionan y se editan los bloques”, dijo Benguella. “Las instancias de bloque son un objeto JSON, y la interfaz de usuario del editor manipula ese JSON, pero para mantener la compatibilidad con versiones anteriores, garantizar la preservación del contenido del usuario en el formato más legible y adoptar los estándares web tanto como sea posible, el editor de bloques no almacena el objeto JSON sino una serialización HTML del mismo en post_content ”.

Esa serialización se analiza y convierte a JSON cuando el editor vuelve a cargar el contenido para editarlo nuevamente. En las etapas finales del análisis, depende del autor del bloque decidir cómo guardar y analizar el objeto.

“Ahora, imagine si un usuario alterara el HTML guardado (serialización) y simplemente pusiera cualquier contenido aleatorio allí”, dijo Benguella. “Es posible que el bloque no pueda analizar el HTML correctamente porque no cumple con sus expectativas (lo que ha sido definido por el autor del bloque), lo que significa que recrear ese objeto JSON para manipularlo no será posible en este momento. .”

Cuando esto sucede, el editor de bloques proporciona al usuario una interfaz para tomar una decisión informada. Pueden intentar "forzar el análisis" del bloque JSON o convertirlo en un bloque HTML o clásico.

Este mismo tipo de invalidación puede ocurrir cuando un desarrollador de complementos actualiza su bloque. Sin embargo, en lugar de cambiar el HTML guardado, el desarrollador cambió las "expectativas" del bloque, modificando la forma en que se guarda y analiza.

“Es por eso que pedimos a los desarrolladores de bloques que proporcionen obsolescencias de bloques que representen el marcado anterior del mismo bloque”, dijo Benguella. “Las obsolescencias también se pueden considerar como fuentes alternativas válidas para el mismo bloque. Esto permite que el editor analice el marcado anterior cuando se carga y guarde el marcado nuevo si se realiza una actualización en el bloque.

WordPress tiene documentación de obsolescencia de bloques. Sin embargo, no es exhaustivo. La mejor fuente para ver las obsolescencias del mundo real es buscar en la biblioteca de bloques de Gutenberg. Los bloques en desuso tienen un archivo deprecated.js .

Benguella dijo que este sistema puede ser frustrante para los autores de bloques. Esto es especialmente evidente en un entorno de desarrollo cuando se realizan cambios. Esto ha llevado a los desarrolladores a solicitar un método para deshabilitar el algoritmo de validación.

“Es algo que no queremos proporcionar en este momento porque, como se explicó anteriormente, la validación también es importante cuando el marcado cambia por otro motivo (edición externa, otro editor, etc.)”, dijo. “Por lo tanto, puede causar la pérdida de contenido para los usuarios sin que se den cuenta de nada. La preferencia en este momento se le da a la conciencia del usuario”.

El equipo ha mejorado el sistema de validación con el tiempo, permitiendo pequeños cambios que no rompen el estado del bloque. También hay un boleto abierto para mejoras en el futuro.