Light lists

1. The providerCopy Anchor Link

A class that implements ProviderInterface answers the table's questions: its columns, tabs, default sort, search placeholder, bulk actions, empty state and rows:

public function getRows(Query $query): array;

Light lets go of the admin session before it calls your provider, so badges, rows and search answers run in parallel: read the session, never write to it here; a write is lost.

The pilot's provider reads the requests through its own backend service. Its empty state says what will appear:

'text' => (string)__('When a business customer fills in the sign-up form, the request shows up here.'),

Each row carries id, url (the row opens it), cells and meta. meta holds the facts row actions test, such as status.

2. Register itCopy Anchor Link

The provider goes in the ProviderPool argument providers (pool table_providers), keyed by the table code, as a \Proxy. The page's layout puts Mrx\Light\Block\IndexTable with that code in content (Your own list and detail pages). A provider class with #[RequiresModule] makes the list not exist while its module is off: the block renders nothing, and the list's data URL answers 404.

3. Bulk and row actionsCopy Anchor Link

• Bulk actions come from getBulkActions(): a label, a route that receives ids[], a resource, a tone and a confirm text for destructive ones. The route is your own JSON controller (Your own list and detail pages).
• Asking from the route. When only the route knows that an action needs the admin's yes (it would replace something the selection holds), it answers HTTP 409 with {"success": false, "message": "...", "confirm": {"title": "...", "message": "...", "label": "...", "param": "confirmed"}} and writes nothing. The list shows that question and, on yes, posts the same ids[] again with param (default confirmed) set to 1. Light's category list does this for "Show in menu" when a language has its own setting.
• Row actions come from a provider that also implements RowActionsInterface: each names a bulk action and the meta it needs, such as "Mark handled" when {status: 'new'}.
• Row-only actions. An action that makes sense on one record at a time, such as opening it in an editor, sets row_only (since 0.3.0): the bulk bar leaves it out, and a row action that names it runs it on that one row (ids[] holds one id). A list whose bulk actions are all row-only gets no checkboxes. Pair it with mode download and target _blank to open a page in a new tab without a popup blocker: the form posts in the click.

The keys of a bulk action:

4. Columns on another module's listCopy Anchor Link

A class that implements ProviderExtensionInterface adds columns and bulk actions to a list it doesn't own, and fills them in decorateRows(). It goes in the IndexTable\ExtensionPool argument extensions (pool table_extensions), keyed by the table code and then by your key. Returns adds a return status column to the orders list:

<item name="orders" xsi:type="array">
    <item name="returns" xsi:type="object">Mrx\Returns\Model\IndexTable\OrdersReturnStatus\Proxy</item>
</item>

Its column and bulk action keys start with <your key>_, and never reuse a key the table has.

• A column or bulk action with another key is skipped and logged, so an extension never replaces the list's own column or action.
• Your columns follow the provider's own, or come right after the column named in after. They are never sortable, and take part in the admin's column choice like the others (hideable, default_hidden).
• Your bulk actions go before the provider's first critical action, and only show with their resource.
• decorateRows() gets the rows of the page that is shown, after getRows(), with the same Query. Only your own columns' cells are taken, matched by row id, so fetch them for the whole page in one query.
• An extension that throws in getColumns() or getBulkActions() adds nothing; one that throws in decorateRows() keeps its columns with empty cells. The list and the other extensions keep working.