Laravel Vuetable Laravel Package

Getting Started

• Install with Composer: composer require santigarcor/laravel-vuetable. The package auto-registers its service provider (Laravel 5.5+ package discovery); if you disable discovery, register it manually.
• Publish the config if you need to change defaults: php artisan vendor:publish --tag=config (or run vendor:publish and pick the package's provider). The config typically controls the default per_page / items-per-page value and default sort column.
• Look first at the package source (src/) before the README. At 27 stars and a 2021 release, the code is small and the README may be stale — the controller base class, the model trait, and the config are the whole surface area.
• First use case: expose a paginated, sortable, searchable JSON endpoint for a vuetable front end. Create a controller that extends the package's base controller, point it at a model (or a query builder), register an API route, and have vuetable hit it. The front end sends page, per_page, sort, order, q, and filter query parameters; the package translates them into Eloquent and returns { data, total, ... }.
• Typical skeleton:

// app/Http/Controllers/Api/UsersTableController.php
class UsersTableController extends VueTableController
{
    protected $model = User::class;
}

// routes/api.php
Route::get('users/table', [UsersTableController::class, 'index']);

<vuetable api-url="/api/users/table" :fields="['name', 'email', 'created_at']" />

Implementation Patterns

• One controller per table, not per resource. The package is opinionated toward a dedicated index endpoint. Keep your normal REST UserController separate; mixing a generic index with table semantics gets confusing fast when you need to return different column sets.
• Override the query, not the controller. The usual extension point is the method that builds the query (often getQuery() / query()). Add with(), select(), scopes, and tenant constraints there instead of duplicating the package logic:

protected function getQuery()
{
    return parent::getQuery()
        ->with(['company:id,name'])
        ->where('is_active', true);
}

• Whitelist sortable columns explicitly. Most vuetable backends sort by whatever the front end sends. Never pass sort directly to orderBy. Maintain a $sortable = ['name', 'email', 'created_at'] array and reject anything outside it. Same for filterable fields.
• Global search (q) should map to a defined set of columns (name, email), not where like across every column — that breaks on numeric/text mixed columns and is slow on large tables.
• Field filters come through as filter=email|jane@… in vuetable conventions. Normalize and validate the field name, then apply where (or where like for text). Treat the operator as fixed per-field; don't parse user-supplied operators.
• Transform output with API Resources. Returning raw Eloquent models leaks columns and makes column renaming painful. Wrap in UserTableResource::collection(...) and preserve the data/total envelope the front end expects.
• Eager-load everything the table renders. Because each row maps to a fields entry, missing relationships produce N+1 queries on paginated tables — the most common production failure with this pattern.
• Multi-tenant / permission scoping belongs in the query override. Every table endpoint is a data-exposure endpoint; make the base controller require an authenticated user or a policy check.
• Testing: assert the JSON contract (data, total, per_page) and assert sorting/filtering behavior, not just status 200. This is cheap and catches the whitelist regressions that matter.

Gotchas and Tips

• It's effectively unmaintained. Last release 2021-03-09. Check compatibility against your Laravel version before adopting; if you're on Laravel 10/11, expect to fork or vendor the package. Pin the version in composer.json.
• Sort/filter injection is the top risk. The package forwards request values into Eloquent; without a whitelist you have an SQL injection / column-enumeration vector. Audit the controller's sort and filter handling on day one.
• count(*) performance. The package needs a total for pagination. For large tables, combine with simplePaginate or move to a keyset approach — the built-in count query is often the slowest part of the request.
• Response shape drift. vuetable is picky about the envelope keys (data, total). If you wrap in Resource::collection without setting $wrap or the controller's response mapping, the front end renders an empty table with no error. Test the raw JSON.
• Relationship columns. Sorting or filtering on a related model's column requires an explicit join in the query override; orderBy('company.name') silently fails or errors.
• Empty filter values. filter=email| arrives as an empty string. Guard against applying where('email', '') — it looks like a bug to users ("why did my table go blank?").
• per_page naming. Vueteable uses per_page; Laravel uses perPage. The package translates it, but if you add a custom paginator or simplePaginate, keep the config's default and cap it (e.g. min($request->per_page, 100)) to prevent per_page=999999.
• Config quirks. The published config sets the default sort and items per page. Changing it affects every table using the package globally — read it before overriding per-controller.
• Extension points: subclass the base controller and override the query-building, column-mapping, and response methods. Prefer a small local abstract controller over patching vendor/. If you must patch, fork under your own namespace and keep the composer constraint pinned.
• Debugging tip: log the normalized query params (sort, order, filter, q, per_page) at the top of the query override. When a table misbehaves, the front end is almost always sending a param shape you didn't expect.