The heart of data-driven pages: loop over records of a data type with a render function and decide the markup yourself.
Records is the block to reach for whenever a page needs to show more than one item from the same data type — a blog index, a product grid, a team overview, or a list of related articles. Because it takes a render function as its child, the markup is entirely yours: a card grid, a table row, a simple list, whatever the page needs.
Combine it with Pagination to split long lists across pages, or with sort and filter props to control which records appear and in what order.
Typical use cases
A webshop product grid is the archetypal use: <Records type='product'> wrapped in a grid layout, with the render function returning a card per product — image, name, price, link to the detail page. A portfolio loops over case-study records the same way, usually rendering just an image and title per item since the visual work should carry the grid. A professional-services site often uses it for a team page, one card per staff member, or for a testimonials section where each record renders inside a Swiper slide instead of a grid cell.
Common mistakes
Leaving off a limit on a data type that can grow large is the most common performance mistake — without one, a growing catalogue or archive eventually renders hundreds of items into the page at once. It's also easy to forget the empty case: if a filter matches zero records, an unstyled blank gap appears where the grid should be — check the result and show a short message instead, so an empty category page still looks intentional rather than broken.
Keep the render function focused on markup, not heavy computation — anything expensive done per record multiplies by the number of items in the list, which is where a seemingly simple page can quietly slow down as content grows.
For the full filter and sort syntax available on type, see datatypes and records. Combined with Search, Records can also power a filtered results view driven by a visitor's query rather than a fixed list. And because the render function fully controls the output, make sure it emits real headings and list semantics where appropriate — a list of articles reads better to assistive technology as an actual list or a sequence of headings than as an unstructured stack of boxes with no semantic meaning.
<Records type='article' limit={6}> {(a) => <Heading>{a.title}</Heading>} </Records>