Liquid gets block and partial tags in developer preview

On 21 July 2026 Shopify opened a developer preview — "Liquid July '26" — introducing two tags: {% block %} and {% partial %}. Both are small additions to the language and both change what a theme can be structured as.

What the two tags do

{% block %} renders a theme block directly from a template. Until now a block existed inside a section, and the section existed inside a JSON template, so composing a page meant going through the section layer whether or not the section added anything.

{% partial %} defines a named region rendered on the server that JavaScript can refresh without a full page load. That is the piece themes have been reimplementing by hand for years: update the cart drawer, swap the variant panel, refresh the filtered grid — each one currently a bespoke arrangement of fetch, parse, and replace, written slightly differently in every theme.

Together they describe a Liquid-first composition model that sits alongside sections and JSON templates rather than replacing them. Nothing is deprecated here.

Why it matters more than the syntax suggests

Theme architecture has been pulled in two directions for years. The editor wants everything to be a section with settings, because that is what merchants can rearrange. Developers want composable units they can render where they need them, without inventing a section wrapper for a component that is not a page region.

{% block %} narrows that gap. A component can be a block, addressable from a template, without pretending to be a section.

{% partial %} narrows a different one. The Section Rendering API has covered this since 2021, and Dawn uses it for the cart, the facets and the variant picker — but it re-renders a whole section, so themes needing something smaller have layered their own conventions on top, and those layers are the least portable code in any theme. A named region, declared where it is rendered, is a finer-grained primitive for the same job.

It also fits alongside the standard storefront events and actions that Shopify introduced in June 2026 and extended in August with cart attribute support. Read together, the platform is supplying the two halves of an interaction: a standard way to signal that something changed, and a standard way to re-render the part of the page affected by it.

What to do about it now

This is a developer preview. Preview behaviour changes, no GA date has been announced, and nothing on an official page commits to one. It does not belong in a client theme this quarter.

What is worth doing is reading your own theme against it. Find the places where you re-render part of the page by hand and ask what they would look like as a partial. That exercise is useful whether or not the preview ships as previewed, because it locates the code in your theme that is hardest to hand over — which is the same code every time.

Two other pieces of housekeeping are already live rather than in preview, and are easier to act on. Liquid parsing is stricter than it was: since January 2026 Shopify auto-rewrites non-compliant files and requires strict-parsable Liquid for new Theme Store and App Store submissions. And automatic CSS subsetting for {% stylesheet %} tags delivers only the CSS relevant to what actually rendered, which changes the arithmetic on how theme styles should be organised.

Neither is exciting. Both affect a theme you are shipping this month, which the preview does not.

The thing to be careful about

A composition model this flexible invites a theme to be assembled from small pieces rendered from anywhere, and that is a good outcome only if somebody decides where the pieces live. The failure mode is not technical. It is a theme where a component is rendered from four templates, three of which pass slightly different arguments, and no file says which one is canonical.

Sections have an accidental virtue here: they are visible in the editor, so a merchant can see what a page is made of. A block rendered directly from a template is not necessarily visible anywhere except the code. Whatever this preview becomes, that trade-off is worth deciding on purpose rather than discovering it during a handover.

If you maintain themes, this is the part of theme development worth watching this year, and it is adjacent to most performance work.