Datagrid Bundle Laravel Package

Getting Started

Before you composer require anything, note the obvious: palabs/datagrid-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config publishing. If you are working in a Laravel app you will need a bridge (or you are maintaining a Symfony codebase side-by-side). If you are in a Laravel-only project, treat this as reference material for how Symfony datagrids are shaped, not something you drop into composer.json.

Assuming a Symfony host:

1. composer require palabs/datagrid-bundle
2. Register the bundle in config/bundles.php (Symfony Flex should do this automatically):

   PaLabs\DatagridBundle\PaLabsDatagridBundle::class => ['all' => true],
   

3. Look here first, in order:
   • src/PaLabsDatagridBundle.php — what services it actually registers
   • DependencyInjection/Configuration.php and Extension.php — the config tree (palabs_datagrid: keys)
   • The Datagrid / Column / Filter classes — this is where the real API lives
4. First use case: render a paginated, sortable, filterable table for a Doctrine entity (e.g. User) in a controller and Twig template. Build the grid against a repository query, pass it to the template, render.

Minimal mental model: you define a grid (columns + data source), the bundle builds a query/DQL pipeline (selects, joins, sort, filter, paginate), and a Twig block renders it. The value is the middle step — you stop hand-rolling if ($request->query->has('sort')) in every controller.

Implementation Patterns

Builder-style grid in a controller (small apps).

$grid = $gridFactory->createBuilder()
    ->setSource($userRepository->createQueryBuilder('u'))
    ->addColumn('id', 'integer')
    ->addColumn('email', 'text')
    ->addColumn('createdAt', 'datetime')
    ->getGrid();

This is the pattern you will copy day-to-day — it keeps the controller declarative and the grid disposable.

Dedicated Grid class (anything non-trivial). Extract grids into App\Datagrid\UserGrid so they can be unit-tested, injected, and reused between list and export actions. This is the single biggest maintainability win: grids in controllers rot fast as filters accumulate.

Pair with filters, not if statements. Configure filters (text, choice, date-range) on the grid and let the bundle read the request. Your controller should only own authorization and the Response.

Pagination at the query level. The bundle paginates the underlying query builder, so make sure your source is a QueryBuilder (or whatever the package expects) — not a hydrated array. If you paginate an array you lose the point.

Twig integration. Render via the bundle's template/block. Override the template by pointing your config at an app-level template if you need custom markup — don't fork vendor templates, because composer update will overwrite them.

Composability. Treat the grid as a view concern: build it in a controller/service, pass a plain object to Twig, keep DQL out of templates. If you find yourself adding {% if %} branches per column, move that logic into a column type.

Gotchas and Tips

• Symfony ≠ Laravel. No php artisan vendor:publish, no Datagrid facade, no config/datagrid.php. Any tutorial you find will be Symfony-shaped. Budget migration time if this is a cross-framework exercise.
• The package is effectively unmaintained. 1 star, 0 dependents. Pin the version ("palabs/datagrid-bundle": "x.y.*"), vendor-lock it, and be prepared to fork. Check the last commit date before adopting — if it pre-dates your Symfony version's major release, test the DI registration carefully.
• Service auto-wiring. Older Symfony bundles assume explicit service IDs (palabs.datagrid.factory style). If autowiring fails, inspect services.xml/services.yaml and either alias the interface or use the legacy ID directly.
• Column type strings are magic. 'integer', 'text', 'datetime' are typically resolved by a type registry — typos fail at render time, not build time. Log or dump the resolved columns in dev to catch mismatches early.
• Query aliasing bites silently. Sorting and filtering map column names to DQL aliases; if your source QueryBuilder uses a non-default alias, filters will target the wrong column or throw. Always set the alias explicitly.
• No pagination without a source. If your data source is a collection/array, sorting and filtering won't push to the DB and large datasets will OOM. Verify with a dataset that exceeds memory before shipping.
• Debugging filters. When a filter appears to do nothing, check (a) the request parameter name matches the filter config, (b) the filter type is registered, (c) the column alias exists on the query. In that order — it's almost always (a).
• Extension points. If the package exposes column type / filter registries, register custom ones in a compiler pass or bundle extension rather than subclassing the grid. Subclassing couples you to the vendor internals and breaks on update.
• Escape to plain Doctrine when needed. For anything the grid can't express (HAVING clauses, window functions, unions), it is usually cleaner to build the query yourself, pass the result in, and lose filtering for that one view — rather than fighting the builder API.