Contract-driven grid

The grid shell in the template is a single element with one piece of data: a pointer to its feed endpoint. There is no server-projected column configuration in the template at all — no column list, no headers, no sort config. The grid learns its own shape from the route it reads.

This is the Presentation Boundary pillar applied to a table: the template carries no data-shaping logic, because the data's shape is declared on the route and discovered, never hand-wired.

The whole template

The live preview on this page is exactly this:

1{% include '@platform-ui/components/runtime/grid-v2.html.twig' with {2    gridId: 'ui-inventory',3    endpoint: '/_feed/inventory',4    emptyMessage: 'The inventory is empty.'5} only %}

That is the entire integration. The grid shell renders with a data-ui-grid-endpoint pointer and nothing else.

How it works

grid-runtime-v2.js issues an OPTIONS request to the endpoint and reads the route's self-describing contract: the output shape (columns and their types), and the route's declared sort, filter, and pager capabilities. It then builds the entire grid — headers, cells, and any controls — from that contract. The runtime never assumes a shape; it asks the route what it serves.

The same OPTIONS contract is the one description every consumer reads. This grid reads it; an API client reads it; a generated SDK reads it. They cannot drift apart, because there is no second source of truth for the data's shape.

A finite, self-degrading feed

The showcase feed declares a finite synthetic dataset (mode: single). The runtime reads that from the contract and does the sensible thing: it renders a clean static table and no pager, because the contract says there is nothing to page through. That is graceful degradation by contract — the UI adapts to what the route actually offers rather than rendering controls that lead nowhere.

For honesty: this showcase grid is an intentionally finite feed with no pager and no sort/filter UI. The OPTIONS contract is the real, working mechanism by which a grid discovers its shape; richer behaviour — interactive column sorting, server-side filtering UI, paged feeds — is part of the contract vocabulary but roadmap from this showcase's standpoint. What you see here is the discovery mechanism itself, demonstrated on a deliberately small dataset so the contract, not the data volume, is the point.

When to use it

Reach for a contract-driven grid whenever the table's shape is owned by a route rather than a screen — admin tables, operational feeds, anything backed by a real query whose columns you would otherwise hand-copy into a template (and then have to keep in sync). You describe the shape once, on the route; every surface that renders it stays correct for free.

How it ties to the philosophy

A hand-wired column config in a template is a presentation-boundary leak: the template now encodes knowledge about the data that belongs on the route. The contract-driven grid closes that leak structurally. The grid is described once, on the route; the template carries only a pointer; and the rendered UI can never disagree with the data it renders — because both read the same OPTIONS contract.