Stacks
Los stacks son el sistema de construcción reutilizable dentro del editor de blocks de Chinaski. Un stack es un grupo con nombre y ordenado de blocks que asignas una vez y reutilizas a través de páginas y posts: una sección hero, una grilla de características, un conjunto de llamadas a la acción que deberían vivir en cada página de producto. En Chinaski son stacks, con anidamiento, herencia, contenido por idioma e historial de revisiones. Esta página explica cómo construirlos y administrarlos.
Construir un stack
Crea un stack bajo Stacks en el área de administración:
- Dale un nombre (único entre los stacks que no han sido eliminados), una descripción y su idioma.
- Agrégale blocks desde el editor de Blocks, en el orden en que deben renderizarse.
- Opcionalmente dale al stack un wrapper de Layout JSON: una configuración de markup al estilo
{"tag":"section","class":"my-cta"}que envuelve una vez el grupo de blocks renderizado.
Los stacks también pueden incluir otros stacks anidados, cada uno con su propio orden de clasificación. Un stack también puede extender a otro: el hijo antepone los blocks del padre delante de los suyos, así que una sección compartida del site puede ensamblarse una vez y extenderse por caso. Si el stack padre se elimina, el enlace del hijo se limpia automáticamente.
Una nota sobre editores y stacks: los stacks están deliberadamente restringidos. Si la lista de entidades permitidas de un editor excluye los stacks, no puede ver ni modificar ninguna pantalla de stacks: la restricción aplica por igual a lectura y escritura.
Asignar stacks a contenido
Los stacks se adjuntan desde el editor de Blocks a una página o un post. Al asignar un stack, existen perillas por emparejamiento: el orden en que aparece el stack, los overrides por instancia, y (avanzado) un JSON de reglas de disponibilidad. Cada stack adjunto es rastreado por el build, así que el manifest de build firmado del site registra qué stacks se usaron por página.
Cada block en el stack puede llevar overrides por instancia, así que el mismo block puede aparecer con contenido distinto en stacks diferentes. Y una página no puede renderizar el mismo block dos veces vía la resolución de stacks: un block ya mostrado por un stack se omite donde más aparezca durante el build de esa página.
Stacks por idioma
Los stacks son conscientes del idioma de dos maneras:
- El stack mismo lleva un campo de idioma, así que pueden existir stacks paralelos para distintos idiomas. Las referencias de blocks internas se resuelven por idioma, recurriendo a un block vacío de idioma (a nivel de site) cuando ese idioma no tiene un block con el nombre referenciado.
- Una traducción de stack (definida por stack + idioma) suministra una lista alternativa de blocks solo para ese idioma. Cuando existe una traducción para el idioma que se sirve, esta reemplaza por completo la secuencia base de blocks para ese idioma reemplazando los overrides de cada block listado. Sin fila de traducción: gana el orden base.
Anidamiento y herencia
- Los stacks anidados permiten a un stack embeber otros stacks, cada uno con su orden de clasificación. El builder los resuelve recursivamente y se protege contra bucles infinitos y cadenas absurdamente profundas (más de cinco niveles de profundidad), así que una mala configuración no puede atascar un build.
- Extender es para estructura reutilizable: haz un stack que extiende a otro (un padre con otros antepuestos); la eliminación del padre limpia el enlace del hijo con elegancia en lugar de corromperlo.
Dónde se usa y qué cambió
El dashboard de Stacks muestra dónde se usa cada stack: la lista "used on" nombra páginas y posts (con un tope de los primeros N y una nota cuando la lista es más larga). Las pantallas de edición muestran stacks de cambios recientes; cada cambio se captura en las revisiones del stack, así que puedes comparar dos revisiones cualesquiera y restaurar una configuración anterior a un stack vivo.
Calidad y auditorías detrás de escena
Cada render de stack es parte del escaneo de calidad del build: los renders de stack contribuyen a los conteos de accesibilidad y enlaces rotos de todo el site que se muestran en el build guard, y cada restauración/actualización/cambio de stack se registra en el audit trail (las entradas "stack restored to selected revision" se auditan). Cuando un reporte de build señala una degradación, los stacks ordenados contribuyen y forman parte de las estadísticas por stack de los mismos datos usados para bloquear un promote defectuoso.