Request lifecycle
When a user changes a table control, InertiaX updates local state, requests the matching data, and accepts the latest result. Your Laravel definition is rebuilt for each request.
One interaction
Section titled “One interaction”- A control sends the change through the table controller.
- InertiaX validates state and updates the table’s URL parameters.
- The Inertia adapter partially reloads the named prop.
- Laravel applies filters, search, sorting, and pagination, then serializes cells.
- The frontend accepts the latest response and reconciles selection and visibility.
URL and local state
Section titled “URL and local state”| State | Persistence and requests |
|---|---|
| Page, page size, sorting, filters, search | Namespaced URL parameters; changes request data |
| Selection | Local IDs for the current result page; no URL write or request |
| Column visibility | Local presentation state; no URL write or request |
Parameters use the table ID as their namespace. Values equal to structural defaults are omitted, and unrelated query parameters are preserved. Browser history navigation to valid table parameters updates state and requests the result immediately.
Request timing
Section titled “Request timing”Search and applied filter changes share a 300 ms debounce. State updates immediately; repeated
changes during the delay produce one request for the latest state. Override it with
<InertiaX prop="users" debounceMs={250} />; use 0 for immediate dispatch.
Page, page-size, sorting, browser-location, refresh, and retry requests dispatch immediately. Search, filters, page-size, and sorting changes reset pagination to page 1.
A newer request supersedes scheduled or in-flight work. The adapter cancels the old Inertia reload when a cancellation token is available. Stale successes and errors are ignored even when the transport still finishes. Only accepted requests emit success or error events.
Result reconciliation
Section titled “Result reconciliation”A server result prunes selected IDs that are absent from the current result and enforces the current selection mode. Column visibility survives while the definition is unchanged; changes to columns, filters, capabilities, or row key reset it to the new defaults.
These reconciliations emit stateChange with source: 'result', not separate selectionChange or
columnVisibilityChange events. See Controller & events.
Status, refresh, and retry
Section titled “Status, refresh, and retry”| Status | Meaning |
|---|---|
idle |
No request scheduled or sent |
scheduled |
Waiting for the debounce delay |
pending |
Request in progress |
success |
Latest accepted request succeeded |
error |
Latest accepted request failed; retry is available |
externalError |
A page result or browser location could not be applied |
disposed |
Session ended |
The built-in UI handles loading and request errors. refresh() requests the current state.
retry() is available only in error and replays the failed request’s state with a new request
identity. For externalError, correct the prop or URL input; retry cannot repair it.
Hide the default refresh control with UsersTable::make('users')->refreshButton(false).
Custom UI can use React hooks and the controller.
Package responsibilities
Section titled “Package responsibilities”| Package | Responsibility |
|---|---|
inertiax/inertiax-laravel |
Table definitions, queries, state validation, and response serialization |
@inertiax/protocol |
Serialized schema and runtime validation |
@inertiax/core |
Client state, requests, controllers, and result reconciliation |
@inertiax/react |
Table UI and customization |
@inertiax/react-inertia |
Inertia props, partial reloads, and browser location |
For data formats, see Protocol reference.