How InertiaX works

You do not need this architecture to build normal application Tables. Start with Your first Table and return here when you need to understand ownership, debug an integration boundary, or build an extension.

At a high level, Laravel produces a Table result and the frontend consumes it. Everything else is separated by responsibility so query code, portable state, rendering, and host navigation do not leak into one another.

Request lifecycle

Laravel Table definition
        ↓
resolve source → columns → filters → state
        ↓
apply filters → search → sorting → pagination
        ↓
protocol 0.1.2 envelope
        ↓
portable Table session
        ↓
React renderer
        ↓ interaction
React/Inertia adapter → partial reload → Laravel

1. A Table definition selects the source, columns, filters, and capabilities.
2. Laravel reads and validates the Table’s namespaced request state.
3. Source operations run in a fixed order: filters, global search, sorting, then pagination.
4. Laravel serializes the result into the canonical protocol envelope.
5. The frontend validates the envelope before creating a Table session.
6. React projects the session into the built-in Table UI.
7. An interaction creates new canonical state. The Inertia adapter performs a partial reload for only that prop, cancels obsolete work where supported, and ignores stale results.

Package responsibilities

inertiax/inertiax-laravel ── produces ──┐
                                       ↓
@inertiax/protocol → @inertiax/core → @inertiax/react
                                            ↑
                              @inertiax/react-inertia

• inertiax/inertiax-laravel declares Tables and executes Eloquent or Collection operations.
• @inertiax/protocol validates and types the wire envelope.
• @inertiax/core owns renderer-independent state, requests, sessions, catalogs, and diagnostics.
• @inertiax/react renders a supplied Table session or envelope. It does not import Inertia.
• @inertiax/react-inertia acquires Inertia props and owns partial reload and browser-location behavior.

The npm and Composer packages version independently. Protocol compatibility is carried inside the envelope, not inferred from matching package versions.

Definition precedence

Reusable Tables support four authoring layers:

1. Base Table defaults.
2. Defaults and declaration methods inherited from parent classes.
3. The concrete class’s protected defaults and data(), columns(), and filters() methods.
4. Fluent overrides applied at the point of use.

Collection mutations are explicit. addColumn() extends a definition, replaceColumn() replaces the matching key, removeColumn() removes it, and setColumns() means clear then add. Filters use the same model. This makes inheritance and per-page overrides deterministic.

Scope on the frontend

React customization resolves in this order:

1. Built-in defaults and renderers.
2. Application customization on InertiaXProvider.
3. Component customization on one InertiaX or InertiaXRenderer.

Component registrations are isolated. A custom renderer for one Table cannot mutate a sibling or a different provider root.

What is intentionally outside the protocol

Authorization, route selection, domain services, arbitrary callbacks, and query implementation remain ordinary application code. The wire envelope contains portable definitions and state—not executable PHP or JavaScript. That boundary is why a custom server operation and its custom React renderer are registered separately under the same namespaced type.