Laravel Simple Datatables And Forms Laravel Package

Getting Started

composer require milenmk/laravel-simple-data-tables-and-forms

The service provider is auto-discovered. Publish the config (and views, if you plan to restyle output) before writing any code:

php artisan vendor:publish --provider="Milen\...\ServiceProvider"

Where to look first, in this order:

1. The published config file — it controls default pagination, view paths, and any asset/CSS assumptions.
2. The bundled Blade views — they define the markup and CSS classes you'll be living with, and they're the cheapest thing to override.
3. The column/field builder classes — this is the actual API surface you'll spend your day in.
4. The README examples — copy one verbatim into a scratch route before adapting it.

First use case: wire up a read-only index table against a model you already have (User, Post, whatever), render it in a Blade view, and confirm pagination/search/sort behave. Only then add a form. Doing the table first isolates install problems (missing config, unpublished views, asset paths) from definition problems.

On the release itself: 2.1.13 ships with nothing but a compare/2.1.12...2.1.13 link — no described features, fixes, or breaking changes. Treat it as a patch. Before bumping, open that diff and read it; a bare changelog link is not the same as "no changes."

Implementation Patterns

Keep definitions out of controllers. Define each table and form in a dedicated class (or a method on a small app/DataTables / app/Forms class) rather than inline in the controller action. These definitions grow — columns, formatters, validation — and inlining them turns a 10-line controller into a 120-line one within a sprint.

One form definition, two verbs. Define create and edit against the same field set and only differ on defaults and submit label. Duplicating the field list is where validation drift starts.

Validation belongs next to the fields. Declare rules in the form definition so the field list and the rule set can't diverge. If you find yourself writing $request->validate([...]) in the controller for the same fields, you've split the source of truth.

Eager load before handing over the query. The builder receives your query, not your model — do ->with('author', 'category') at the call site. Table rendering frequently touches relations per row, and this is the single most common source of N+1 in these screens.

Thin controller, fat definition:

public function index()
{
    $table = PostTable::make(Post::query()->with('author'));

    return view('posts.index', compact('table'));
}

public function store()
{
    PostForm::make()->validateAndSave(request());

    return redirect()->route('posts.index');
}

Extend via callbacks, not forks. Most column renderers accept a closure for custom output (badges, links, formatted dates). Reach for the closure first; only override the Blade view when you need structural markup changes, and only fork the package when neither works.

Test the definition, not just the page. Where the builder exposes its resolved columns/fields, assert on that array in a unit test — it catches "I renamed the column and broke the sort" far faster than a feature test. Keep one or two feature tests on the actual endpoints for the rendering path.

Gotchas and Tips

• Published views are frozen. Once you run vendor:publish, upgrades no longer touch your copies. After every package bump — including 2.1.13 — diff your published views against the package's resources/views in the new tag. Silent markup/attribute changes are the usual upgrade break.
• Sortable/searchable columns must be whitelisted. Never pass a user-supplied ?sort= straight into orderBy. Map the request key against your declared columns and reject anything else; this is the most common injection footgun in table packages.
• fillable vs. form fields drift silently. A field in the form that isn't mass-assignable just gets dropped — no error. Add a test that posts the full field set and asserts the attributes landed.
• Config caching in production. php artisan config:cache after changing the published config, or you'll debug a setting that appears to have no effect.
• Clear compiled views when overriding. php artisan view:clear when your Blade overrides don't seem to apply.
• Debug the generated SQL, not the output. DB::listen(fn ($q) => logger($q->sql)) around the table render will show you sorting/pagination/search clauses immediately — far quicker than reading the builder source.
• Pin the version. "milenmk/laravel-simple-data-tables-and-forms": "~2.1.13" rather than ^2.1. Given how little 2.1.13 documents about itself, you want deliberate upgrades and a readable diff, not whatever composer update pulls next Tuesday.
• Extension points worth knowing before you fork: custom column/field types, per-column render closures, and view overrides. In that order — each is less invasive than the last resort of copying package source into app/.