Datagrid Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. v0.5.0 does not change that: the release notes read Support SF 5 — a Symfony version-compatibility bump, nothing more. There is still no DataGridServiceProvider, no config publish tag, no facade. composer require freezy-bee/datagrid-bundle in a Laravel app will install code but register nothing — Laravel's container never sees it, because the package's entry point is a Bundle subclass wired through Symfony's config/bundles.php and DI compiler passes.

So the first decision is unchanged: are you in a Symfony app, or are you trying to bring this into Laravel?

If you are in a Symfony app (the intended path):

1. composer require freezy-bee/datagrid-bundle — v0.5.0 is the version to take if you're on Symfony 5; it is the only release that will resolve there
2. Register FreezyBee\DataGridBundle\DataGridBundle in config/bundles.php
3. Check Resources/config/ for the service definitions and the configuration tree — that tells you the alias and any required options faster than the README
4. Build your first grid as a PHP class (colonnes + filters), inject it into a controller, pass it to Twig, render it
5. Open DependencyInjection/Configuration.php next — that is the authoritative list of what is configurable; docs for a low-star bundle will be thinner than the code

If you are in a Laravel app (the realistic case):

Don't install it expecting a working grid, and do not read v0.5.0 as a sign of renewed life for that purpose. It is a reference implementation: skim the column/filter/sort classes and the query-builder abstraction, then reimplement the parts you need against Eloquent. Your first real use case is "I want a declarative grid object with columns, filters, sorting and pagination that I can unit test" — this package is a decent blueprint for that shape, and Laravel has stronger native options for the actual feature (Filament tables, Orchid, Laravel DataTables, or a hand-rolled Livewire table).

Implementation Patterns

Grid-as-a-class (the pattern worth stealing). The bundle's core idea is that a grid is a configured object, not a blob of view logic: you declare columns, filters, sortable fields, and page size in one place, then feed it a data source. That separation is the durable lesson — it survives the framework change, and it survives this release too.

Controller → grid → template. The normal flow is: controller constructs/obtains the grid, applies the request (page, sort, filters), passes the grid to the view, view renders it. Request-to-grid binding is where the value is; hand-rolling it in Blade is what people usually regret.

Query-builder/ORM coupling. Expect tight Doctrine integration — the grid consumes a query builder, not a plain array. On Laravel you would write a thin adapter that maps Eloquent's Builder (plus paginate()) onto whatever interface your grid object expects, and keep the grid class ignorant of Eloquent.

AJAX / partial refresh. Grid bundles of this vintage typically support rendering a partial for XHR requests. If you're porting, model this as a Blade partial plus a JSON endpoint rather than replicating the Twig include structure.

Laravel-side integration tips if you persist:

• Wrap it behind your own DataGrid contract and never let controllers touch the vendor classes directly. The package is effectively unmaintained; the indirection is your escape hatch.
• Bridge the Symfony container manually only if you truly need it (e.g. Symfony\Component\DependencyInjection is already in Laravel's vendor tree via other Symfony components). Tagged services and compiler passes will not run — you'd have to instantiate and pass dependencies yourself.
• Rewrite Twig templates as Blade. Don't try to run Twig inside Laravel for one grid; you'll spend more time on the Twig bridge than on the grid.
• Reuse only the framework-agnostic pieces: column definitions, filter value objects, sorting/pagination value objects.

Gotchas and Tips

v0.5.0 is a compatibility bump, not a revival. The single-line note Support SF 5 means the bundle's composer.json now admits Symfony 5. It does not announce PHP 8.2/8.3 work, Symfony 6/7 support, or any Laravel-adjacent change. Treat the project as frozen-and-patched: it now works on one more Symfony major, and that's the whole story. If your Symfony app is on 6 or 7, this still will not install.

Pre-1.0 semver. The jump is 0.4 → 0.5, which under semver permits breaking changes without a major bump. The release note mentions only Symfony 5, but diff DependencyInjection/, the column/filter signatures, and the Twig templates against your pinned version before upgrading an existing grid. Loosening the Symfony constraint to ^5 sometimes drags along a doctrine/orm or twig/twig bump that changes template behaviour.

Composer constraints still fight modern Laravel. Previously the era-appropriate constraints (Symfony 3/4, PHP 7.x) clashed with Laravel's Symfony 6/7 components. v0.5.0 relaxes them toward Symfony 5, but modern Laravel ships Symfony 6/7 components, so you still land in --with-all-dependencies resolution territory you don't want — and you still gain nothing, because the bundle never registers in Laravel.

Symfony 5 is itself old. If you adopt v0.5.0, you're adopting support for a Symfony major that is at or past end of maintenance. Verify the exact constraint the release added (^5.0? ^5.4?) in composer.json before assuming you can stay on a patched minor; and plan the move to Symfony 6+ separately, because this package will not follow you.

Framework mismatch is total, not partial. It is not "Symfony-flavored but usable." Bundle registration, DI, Twig, Doctrine, and the event dispatcher are all assumed. Every one of those has a Laravel equivalent with different semantics — that's five bridges for a grid.

Doctrine vs Eloquent. Most of the interesting code is Doctrine QueryBuilder manipulation. Eloquent's builder API diverges on joins, where groupings, and hydration, so a naive port produces subtly wrong filters.

Twig templates. Overriding means Symfony bundle resource overriding. In Laravel that mechanism doesn't exist; you'd be copying templates into resources/views and rewriting them. On Symfony 5, bundle inheritance paths and the @FreezyBeeDataGrid/ notation are worth confirming in the source if you upgrade.

Debugging. In Symfony, use the profiler and the DI debug commands (debug:container, debug:config) — service wiring is the usual failure point, and a constraint bump is exactly when wiring breaks. In Laravel you have none of that for this package; you're debugging by dd() in code you didn't write. Budget for that.

Extension points (if you do use it in Symfony). Custom column types and filters are typically registered as tagged services — that's the clean place to add behavior. Template overrides go through bundle config. Both are only as documented as the repo is, which is to say: read the source.

Licensing is fine. MIT, so copying concepts or code snippets into your own package is unproblematic. That remains the best use of this dependency.

Recommendation. Unchanged for Laravel: do not adopt. One release note saying "Support SF 5" does not make a Symfony bundle a Laravel package, and it does not restore upstream momentum — it buys Symfony 5 apps a few more years. Take the grid-as-a-class idea, use a maintained Laravel-native table solution, and move on. For a Symfony app on 5.x: now installable, still treat it as frozen and plan the migration away from it before the Symfony 6 upgrade. For Symfony 3/4 apps: this release does not help you, but it does tell you the maintainer's last act was a compatibility bump rather than a feature — expect no more.