Responsivetable Laravel Package

Getting Started

This is a first (1.0.0) release, so treat the release notes as a feature summary and the README as the actual API contract. The notes describe the mechanism ($tableStyle on a Nova resource, breakpoint-based column hiding) but not the exact array shape or key names — read those first before writing config.

Minimal path:

1. Install into a Nova 4.x+ app:

   composer require <vendor>/nova-responsive-table   # exact name per README
   php artisan nova:assets     # only if the README says assets must be published
   

   Nova 4 packages are usually auto-discovered; check the README for a manual NovaServiceProvider::tools() or Nova::script() registration step before assuming zero config.
2. Pick one wide resource — the one where users already scroll horizontally. That is where the package pays for itself immediately.
3. Declare the style on that resource only:

   public static $tableStyle = [
       // Illustrative shape only — confirm keys against the README.
       // Goal: identity columns always visible, detail columns drop first.
   ];
   

4. Verify with a real record set at ~375px, ~768px, ~1024px, and ~1440px, with the Nova sidebar both collapsed and expanded.

First useful use case: a resource with 10+ columns (name, email, phone, status, owner, created_at, updated_at, relations) where the first three columns are enough to identify a row. Keep identity + status + row actions visible at every width; let timestamps and secondary relations disappear first.

Implementation Patterns

Centralise the breakpoint convention. Put $tableStyle on a base resource class or a ResponsiveColumns trait and override per resource. Scattered definitions drift within a sprint and you end up with email hidden on Orders but visible on Invoices for no reason.

Rank columns in tiers, not by type. A workable convention:

• Tier 1 (always): primary identifier, status/badge, row actions.
• Tier 2 (≥md): contact/owner, key metric, short enum.
• Tier 3 (≥xl): timestamps, long text, BelongsTo relations, booleans.

Pair with Nova's own visibility for genuinely expensive fields. Responsive hiding is presentational; it will not stop a computed field or eager-loaded relation from being built. If a column is costly and non-essential in the index, use ->hideFromIndex() instead — or both, where the field is useful on desktop but expensive to compute for mobile sessions.

Roll out resource-by-resource. Land the package with one resource, get sign-off on the breakpoints, then port the trait. A single PR converting twenty resources at once is unreviewable in a browser and impossible to QA.

Test in CI as a visual concern. There is no PHP-level assertion for "column hidden at 768px". Either add a handful of Dusk viewport snapshots around the 768/1024 boundaries, or accept manual QA and document the checklist — but decide explicitly, because reviewers will ask how this is tested and "it's just CSS" is not an answer for a shared table.

Coordinate with the searchable/sortable set. A column that is sortable but hidden at md leaves users able to sort by something they cannot see. Either keep sortable columns in a visible tier or accept the invisible-sort-state tradeoff knowingly.

Gotchas and Tips

• Breakpoints are viewport-based, table width is not. Nova's sidebar, page padding, and full-width vs. constrained content areas mean the table can be narrow on a 1280px screen. The failure mode is a column vanishing in a maximised desktop window with the sidebar open. Test the intermediate widths (900–1100px), not just phone vs. desktop.
• Hidden columns are still in the payload. Data is fetched server-side before CSS/JS hides it; do not expect a mobile performance win or reduced query count. If that is the goal, this package is the wrong lever — use hideFromIndex() and selective eager loading.
• Confirm the interaction with Nova's own $tableStyle. Nova resources historically have their own $tableStyle concept (e.g. 'tight'). Check what happens if both are in play: does the package read the string, replace it, or type-check and bail? Getting this wrong produces a silently unstyled table, which is easy to miss in a dark theme.
• "Nova 4.0 and later" is an untested claim. The notes predate Nova 5. Pin ^1.0 and explicitly smoke-test the index view on whatever Nova major you actually run before assuming compatibility; major Nova versions rework the table component.
• display:none removes content from assistive tech. If a column carries the only meaningful description of a row at mobile widths, screen-reader users lose it. Keep a short identifier visible at all sizes and don't hide status/state indicators.
• Actions and metrics columns need separate attention. Inline action dropdowns and metric cards are commonly affected by table layout; verify they don't clip or wrap at narrow widths.
• Exports and print ignore your styling. Excel/CSV exports still contain every field. That is usually desirable — state it in the docs you hand to users so nobody files a "hidden column appeared in the export" bug.
• Cached/compiled assets. After changing the style config, if the effect doesn't appear, clear Nova's assets (php artisan nova:publish / nova:assets) and hard-reload before debugging your config — a stale compiled bundle mimics a broken $tableStyle almost perfectly.
• Extension point to watch: since the package ships no external dependencies, theming is likely CSS-variable or class-based. If your app has a custom Nova theme, check the generated class names are overridable and note them, so a future theme change doesn't fight the package.