Skip to content

Registration & diagnostics

Use namespaced identifiers such as acme/role for custom column, filter, and icon types. The server’s type must match the key registered in React.

Start with Custom columns or Custom filters for complete examples.

Pass a TableCustomizationOptions object to InertiaXProvider for application-wide registration, or to <InertiaX table={...} /> for one table. Resolution is built-in → provider → component.

import type { TableCustomizationOptions } from '@inertiax/react';
const usersTable = {
cellRenderers: [
{ operation: 'register', key: 'acme/role', value: RoleCell },
],
} satisfies TableCustomizationOptions;

Here, RoleCell is the renderer from Custom columns. register adds a new key; replace requires an existing key. Duplicate adds and missing replacements fail with catalog and component context.

A column key selects data; its type selects the cell renderer. A filter type selects the input, while clause keys identify server comparisons. Registering a renderer does not add query behavior.

The default fallback: 'allow' policy renders a fallback and records INERTIAX_CATALOG_FALLBACK_USED with the missing key. Make missing registrations fatal during development:

<InertiaXProvider runtimeOptions={{ diagnostics: { fallback: 'error' } }}>
<App />
</InertiaXProvider>

Or observe diagnostics while keeping fallbacks:

<InertiaXProvider
runtimeOptions={{
diagnostics: {
fallback: 'allow',
onDiagnostic(diagnostic) {
console.warn(diagnostic.code, diagnostic.key, diagnostic.componentId);
},
},
}}
>
<App />
</InertiaXProvider>

These are provider fragments for the application entry point. Invalid envelopes, callbacks, and registration operations fail independently of the fallback policy.

Use the pipeline option only for an integration that must transform a validated envelope. A stage failure or invalid output rejects the update and retains its cause. For ordinary presentation changes, use cells or regions.