Download the PHP package raprmdn/laravel-inertia-datatables without Composer

Laravel Inertia Datatables

This package is currently in beta. It is usable, but the public API may still change before v1.0.0.

Introduction

raprmdn/laravel-inertia-datatables is a backend-first Laravel query builder for server-side datatables. It supports:

• Eloquent and Query Builder queries
• Declarative, allowlisted column definitions
• Search, exact filters, JSON filters, date ranges, and custom filters
• Direct, relation, and custom sorting
• Eager loading and relation counts
• Paginated or collection output

The package does not require Inertia, React, Tailwind, Ziggy, shadcn/ui, or an npm package. Use it with Inertia, API resources, Blade, or any Laravel response.

ColumnDefinition is the primary public API. Define request-facing column keys with Column::make() or Column::group(), enable only needed capabilities, and register them with columnDefinitions().

Installation

Configuration

Optional:

Default configuration:

Quick Start

Define public keys and pass raw request values to the builder. Definitions map those keys to trusted backend columns during make().

Example request:

Unknown filter and sort keys are ignored because they have no matching enabled definition.

Column Definitions

Public Keys and Sources

Column::make() creates one ColumnDefinition:

The first argument is the public request key. The optional second argument is a trusted default backend source.

Do not pass request input as a source. Sources are developer-defined SQL columns or Eloquent relation paths.

Capabilities

Definitions expose only capabilities you enable:

Available capability methods:

dateRange() enables date filtering directly. It does not require filterable().

Source Overrides

Each capability can override the default source:

Source resolution order:

1. Capability-specific source
2. Default source
3. Public key

Column Groups

Use Column::group() when columns share capabilities:

Associative entries map public keys to backend sources:

Groups expand to independent definitions during registration. A capability source passed to a group is copied to every member; use separate definitions when members need different overrides.

Registration and Merging

Register definitions or groups with columnDefinitions():

Registration is additive. Repeated public keys merge:

• Capabilities accumulate.
• Later explicit sources, strategies, and callbacks win.
• Alias maps merge, with later values replacing matching aliases.

Definitions may be registered before or after applyFilters() and applySort(). Resolution happens during make().

Request Resolution

applyFilters() accepts raw column:value strings. applySort() accepts a public key or null:

Filter values split on the first colon, so values may contain more colons. Malformed entries, non-string entries, and unknown public keys are ignored.

Searching

Search reads the configured search query parameter:

Enable search on one definition or a group:

Search behavior:

• Searchable sources are developer-defined.
• Search values use query bindings.
• Columns are OR-grouped inside one parenthesized condition.
• Existing base query constraints remain outside that group.
• Matching is case-insensitive through LOWER(column) LIKE ?.
• Empty search values leave the query unchanged.

For Eloquent, dotted sources are relation paths:

For Query Builder, dotted sources are SQL table or alias references.

Filtering

Filters use the configured filters query parameter and column:value format:

Values for one public key are OR-grouped. Different keys are applied as separate AND groups. Values use query bindings.

Filter Aliases

Map friendly request values to backend values:

Aliases are exact and case-sensitive. Unknown values pass through unchanged. Values may be strings, integers, floats, booleans, null, or JSON-compatible arrays.

NULL Values

Exact values NULL and NOT NULL use whereNull() and whereNotNull():

Prefer aliases when exposing these operations to clients.

JSON Filters

Scalar JSON paths normally use exact filtering:

Use jsonContains() for JSON arrays or containment:

Array alias values require jsonContains() or filterUsing(). SQLite supports scalar arrays and object maps; nested arrays need a custom filter because SQLite lacks native structural JSON containment.

Date Ranges

Enable ranges on the public base key:

Clients send _from and _to keys:

Either boundary may be omitted. Empty boundaries are ignored. Dates use the configured Carbon format, defaulting to d-m-Y. Invalid dates throw InvalidArgumentException.

The from boundary starts at midnight and is inclusive. The to boundary is exclusive at the next midnight, preserving the complete selected day including fractional-second timestamps. Comparisons do not wrap the database column in a date function.

An explicitly filterable key such as created_at_from wins before suffix detection.

Custom Filters

Use a trusted callback when exact, relation, JSON, and date filtering are not enough:

filterUsing() selects the strategy but does not enable filtering; also call filterable(). The callback receives the original query and all alias-resolved values for that public key. It runs once during make(), should only add trusted constraints, and should not execute the query. Exceptions propagate.

Keep authorization, tenancy, and visibility constraints in the base query, not in optional datatable filters.

Sorting

Sorting uses the configured column and direction parameters:

Define public sort keys, then pass the requested key to applySort():

Unknown, missing, or null public keys use fallback ordering from orderBy(). The fallback column need not be sortable.

Directions asc and desc are accepted case-insensitively. An invalid request direction uses the fallback direction. The fallback direction itself must be asc or desc; Laravel rejects invalid values during make().

Custom Sorting

Use sortUsing() for calculated values or application-specific ordering:

sortUsing() does not enable sorting; also call sortable(). Callback return values are ignored.

Relations

Column Paths

Eloquent definitions use relation methods followed by the final column:

Search and filtering support nested relation paths. Date ranges also support dotted Eloquent paths.

Relation Sorting

Eloquent sorting supports BelongsTo and HasOne, including nested and self-referencing relations. Sorting uses correlated scalar subqueries, keeps relation constraints and related-model global scopes, and does not join the base query.

HasMany and BelongsToMany sorting is ambiguous and throws InvalidArgumentException. Missing or non-relation methods also fail deterministically. Use sortUsing() when custom aggregation is intentional.

Eager Loading

with() and withCount() accept one relationship or an array:

Repeated calls accumulate. Duplicate plain names are retained once. Laravel count aliases remain valid exact strings.

Constrained definitions are preserved:

A later constrained definition replaces an earlier constraint for the same key. A constrained definition remains authoritative over a plain duplicate.

Pagination & Collections

Pagination

Pagination is the default result type. make() returns a length-aware paginator, appends current request query parameters, and applies the configured link window.

The configured limit request parameter overrides perPage(). The final value is clamped from 1 through pagination.max_per_page.

Collections

Collection output is unpaginated and ignores request and configured page-size behavior. Eloquent returns models; Query Builder returns plain objects.

Search, filters, date ranges, and sorting preserve an existing select(). Relation sorting does not add helper columns or replace selected columns.

Query Builder

Query Builder supports search, exact and custom filters, JSON filters, date ranges, sorting, pagination, and collections. Define columns the same way as for Eloquent.

It does not resolve Eloquent relations. with() and withCount() become no-ops, and dotted search or filter sources are SQL table or alias references.

Supply joins before passing the query to DataTable::query(). Aliases in dotted sources must match query aliases. Qualify overlapping columns and select the base table, such as records.*, to prevent joined values replacing result properties.

For Query Builder sorting only, a multi-part source such as organization.country.name becomes organization_country.name; create that alias yourself. Search and filter sources are used as configured.

API Reference

Column API

Names and sources must not be empty. Invalid definitions throw InvalidArgumentException.

Manager API

Each query() call returns a new mutable builder, so state does not leak between query chains.

Builder API

Execution order is relations, search, filters, date ranges, sorting, then pagination or collection retrieval.

Request Parameters

All keys are configurable in inertia-datatables.query_params.

Examples

Example Application (GitHub): https://github.com/raprmdn/laravel-inertia-datatable

Inertia Controller

Inertia is one response option, not a package requirement:

API Resource

Testing

Run package tests:

Equivalent direct command:

For package changes, also validate Composer metadata:

Limitations

• Package remains beta; public API may change before v1.0.0.
• Eloquent relation sorting supports BelongsTo and HasOne, not HasMany or BelongsToMany.
• Query Builder joins and aliases must be supplied by the caller.
• String column and relation names may not receive complete IDE autocomplete.
• Generic frontend filter operators are not provided; use trusted filterUsing() callbacks for application-specific behavior.
• Frontend components are not included or required.

Legacy API

Legacy APIs remain fully supported for backward compatibility. New code should use column definitions.

Available legacy methods:

• DataTable::parseFilters()
• DataTable::parseSort()
• searchable()
• allowedFilters()
• filterUsing() on the builder
• applyDateRanges()
• allowedSorts()

Existing parser flow remains valid:

Legacy allowlists remain required because parser output alone does not authorize SQL columns. Legacy JSON containment paths remain configured through json_columns. Definitions and legacy methods may coexist; legacy setters keep their replacement behavior while columnDefinitions() remains additive.

Contributing

Issues and pull requests are welcome while the package is in beta. Keep changes focused and backend-first. Public API changes require regression tests and README updates.

License

This package is open-sourced software licensed under the MIT license.