Liquid estrena las etiquetas block y partial en vista previa
Dos etiquetas nuevas permiten renderizar un bloque desde la plantilla y refrescar una región con nombre sin recargar la página. Los temas ganan un modelo de composición.
Actualización12 de agosto de 20264 min de lectura
El 21 de julio de 2026 Shopify abrió una vista previa para developers —"Liquid July '26"— que introduce dos etiquetas: {% block %} y {% partial %}. Ambas son añadidos pequeños al lenguaje y ambas cambian cómo puede estructurarse un tema.
Qué hacen las dos etiquetas
Desliza la figura para verla completa
{% block %} renderiza un bloque de tema directamente desde una plantilla. Hasta ahora un bloque existía dentro de una sección, y la sección dentro de una plantilla JSON, de modo que componer una página obligaba a pasar por la capa de sección aportara esta algo o no.
{% partial %} define una región con nombre renderizada en el servidor que JavaScript puede refrescar sin recargar la página entera. Esa es la pieza que los temas llevan años reimplementando a mano: actualizar el cajón del carrito, cambiar el panel de variante, refrescar la cuadrícula filtrada; cada una hoy es un apaño propio de fetch, parseo y sustitución, escrito ligeramente distinto en cada tema.
Juntas describen un modelo de composición centrado en Liquid que convive con las secciones y las plantillas JSON en vez de sustituirlas. Aquí no se depreca nada.
Por qué importa más de lo que sugiere la sintaxis
La arquitectura de temas lleva años tirada en dos direcciones. El editor quiere que todo sea una sección con ajustes, porque es lo que los comerciantes pueden reordenar. Los developers quieren unidades componibles que puedan renderizar donde las necesiten, sin inventar una sección envoltorio para un componente que no es una región de página.
{% block %} estrecha ese hueco. Un componente puede ser un bloque, direccionable desde una plantilla, sin fingir que es una sección.
{% partial %} estrecha otro distinto. La Section Rendering API cubre esto desde 2021, y Dawn la usa para el carrito, los filtros y el selector de variantes — pero renderiza una sección entera, así que los temas que necesitan algo más pequeño han apilado convenciones propias encima, y esas capas son el código menos portable de cualquier tema. Una región con nombre, declarada donde se renderiza, es una primitiva más fina para el mismo trabajo.
También encaja con los eventos y acciones estándar de storefront que Shopify introdujo en junio de 2026 y amplió en agosto con soporte para atributos de carrito. Leídos juntos, la plataforma está aportando las dos mitades de una interacción: una forma estándar de avisar de que algo cambió y una forma estándar de volver a renderizar la parte de la página afectada.
Qué hacer ahora
Esto es una vista previa para developers. El comportamiento de una vista previa cambia, no se ha anunciado fecha de disponibilidad general y ninguna página oficial se compromete a una. No tiene sitio en el tema de un cliente este trimestre.
Lo que sí conviene hacer es leer tu propio tema contra ella. Localiza los sitios donde vuelves a renderizar parte de la página a mano y pregúntate cómo se verían como partial. Ese ejercicio es útil salga o no la vista previa tal cual, porque localiza el código de tu tema que más cuesta traspasar, que es siempre el mismo.
Hay otras dos tareas de mantenimiento que ya están vivas y no en vista previa, y son más fáciles de atender. El parseo de Liquid es más estricto que antes: desde enero de 2026 Shopify reescribe automáticamente los archivos no conformes y exige Liquid estrictamente parseable en los envíos nuevos a Theme Store y App Store. Y el subconjunto automático de CSS para las etiquetas {% stylesheet %} entrega solo el CSS relevante para lo que de verdad se renderizó, lo que cambia la aritmética de cómo conviene organizar los estilos de un tema.
Ninguna de las dos es emocionante. Ambas afectan a un tema que estés publicando este mes, cosa que la vista previa no hace.
Lo que hay que cuidar
Un modelo de composición tan flexible invita a montar un tema con piezas pequeñas renderizadas desde cualquier sitio, y eso solo es un buen resultado si alguien decide dónde viven las piezas. El fallo no es técnico. Es un tema donde un componente se renderiza desde cuatro plantillas, tres de las cuales le pasan argumentos ligeramente distintos, y ningún archivo dice cuál es la canónica.
Las secciones tienen aquí una virtud accidental: se ven en el editor, así que un comerciante puede ver de qué está hecha una página. Un bloque renderizado directamente desde una plantilla no es necesariamente visible en ningún sitio salvo en el código. Sea lo que sea en lo que acabe esta vista previa, ese equilibrio conviene decidirlo a propósito y no descubrirlo durante un traspaso.
Si mantienes temas, esta es la parte del desarrollo de temas que conviene vigilar este año, y está pegada a casi todo el trabajo de rendimiento.