Simple Datatables Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for table UIs: Deciding whether a screen needs a lightweight, client-side (in-memory) datatable versus a heavier server-driven grid. This bundle is the "lighter table needs" option and is explicitly supported, not deprecated.
• Build vs. buy for table functionality: Choosing between hand-rolling search/sort/pagination in Twig + Stimulus versus adopting a thin MIT-licensed integration around the simple-datatables JS library.
• Roadmap and consolidation: Informing whether to standardize on one table stack (simple-datatables-bundle for in-memory tables vs. grid-bundle/api-grid-bundle for API Platform-backed tables), and sequencing any per-page migration.
• Migration planning: Triggering an inventory of existing component calls, Stimulus mounts, PHP Column objects, styles, and event handlers before porting a page — and validating the perPage → pageLength rename and removal of backend.
• Use-case fit: Appropriate for admin lists, CRUD index pages, and small/medium result sets rendered server-side; not for very large datasets requiring server-side processing.

When to Consider This Package

Adopt when:

• The application is PHP/Symfony (Twig + Stimulus/importmap). This is a Symfony bundle, not a Laravel package — treat it as a PHP-ecosystem option and confirm framework fit before planning.
• You need in-memory datatables with search, sorting, pagination, and page sizing on modest result sets.
• The app does not already use API Grid, and requirements don't justify the heavier Grid/API Grid dependency graph.
• You value a small, MIT-licensed, low-lock-in integration over a large framework.
• You can accept a minor migration surface (perPage → pageLength, drop backend, keep controllers lazy, no global DataTables CSS autoimports).

Look elsewhere when:

• You need server-side processing or API Platform pagination/facets — use survos/api-grid-bundle/Grid instead.
• The team is not on Symfony (e.g., plain Laravel) — the integration value is low.
• You require large-community support, long-term vendor guarantees, or extensive extension coverage — with ~10 stars and a single-maintainer footprint, this is a convenience wrapper, not a strategic dependency.
• A prior explicit library choice was already made for the app — respect it; don't re-litigate per page.
• You'd be tempted to add a second DataTables setup or global CSS imports — that's an anti-pattern the package docs warn against.

How to Pitch It (Stakeholders)

Executive summary: survos/simple-datatables-bundle is a small, MIT-licensed Symfony integration around the simple-datatables JavaScript library. It gives us functional, familiar table UX (search, sort, pagination) with minimal code and low lock-in, while a documented migration path exists to the heavier Grid stack if requirements grow. It is a tactical convenience layer, not a strategic platform bet.

To engineering: Evaluate against the alternative of building table behavior ourselves or adopting Grid. Keep the integration thin and controller-local; avoid global CSS and duplicate DataTables setups. Use the package's verification checklist (search, sorting, pagination, page sizes, empty/custom rows, links, Turbo reconnects, actual asset downloads) before rollout, and don't infer Grid is preferred — confirm the library choice per application. Verify against published package releases, not just local links.

Risks to flag: modest adoption (~10 stars) and single-maintainer risk argue for keeping usage shallow and standards-aligned so we can swap it out. Frame adoption as a reversible, scoped decision with a clear migration escape hatch, not a foundational commitment.