Nova Table Field Laravel Package

Product Decisions This Supports

• JSON column vs. normalized relational schema — a product decision, not an implementation detail. The field persists an entire editable grid into a single Eloquent attribute as JSON. That means "ship a pricing matrix this sprint" becomes one migration plus a few lines of Nova config instead of three pivot tables, a join model, and a CRUD surface. The PM owns the framing question: will the business ever need to query, join, filter, aggregate, or report on these rows individually? If yes, normalize. If the rows are admin-curated configuration that is only ever read inside Nova, this is the cheaper path — and that assumption should be written down with a named owner and a review date.
• Internal-tooling roadmap and admin-panel scope. Any backlog item phrased as "ops needs to edit X without filing an engineering ticket" is a candidate: shipping rate cards on Product, per-region tax tables, tiered discount bands on Plan, seasonal surcharges, feature-comparison grids, per-client fee schedules. This field collapses a bespoke CRUD screen — controller, FormRequest, Blade views, feature tests — into a handful of lines in a Nova resource, moving internal-tool epics from days of estimate to hours and freeing capacity for customer-facing work.
• Build vs. buy for back-office surfaces. For teams already licensed on Laravel Nova, this is not a new vendor decision — it is a near-zero-cost capability extension. It shifts "build a small grid editor" from build to configure, and belongs in the existing admin-platform line item alongside recurring Nova seats.
• Feature sequencing and validation/audit strategy. Because the payload is unstructured at the database layer, product must decide before adoption what validation, audit history, approval flow, and permissions surround the grid. A rate card that a user can edit with no audit trail is a compliance problem, not an engineering detail. Write the requirement down first; retrofitting it after finance asks "who changed this price?" is far more expensive.
• Data portability and reporting commitments. If sales, finance, or analytics will eventually want these values in BI or an export, this decision creates downstream work: flattening JSON, ETL, or a later relational migration. Treat "we will only ever view this inside Nova" as an explicit, documented assumption — not an implicit one.
• Discovery velocity and prototype de-risking. During discovery, the field stands up a realistic, editable admin surface for user testing before the team commits to a permanent data model. That lets you validate a workflow (do users actually think in rows and columns here?) before paying for the expensive schema work.
• Schema-change velocity. Because column definitions live in code (columns()) and data lives in JSON, adding a column to the grid is a config change, not a migration. That directly buys product optionality: you can iterate on the shape of the data with users for weeks before committing to a relational design.

When to Consider This Package

Adopt when most of the following hold:

• Stack is Laravel with an already-licensed Nova install. This package is a Nova field, not a standalone grid component. Introducing Nova for this field is the wrong reason; Nova's licence must already be justified by other admin needs. Without Nova, the package is inert.
• The data is small, admin-curated, and rarely machine-consumed — dozens to low hundreds of rows, edited by a handful of trusted internal users, not by customers.
• The grid shape is semi-structured or variable — columns differ per row, per client, or per product line, where a fixed relational schema would mean frequent migrations and constant engineering tickets.
• You can accept JSON-in-a-column as the system of record, with its known limits on indexing, joins, aggregate queries, and referential integrity.
• You need something fast and disposable — internal tooling, a discovery prototype, a one-off ops screen — where the re-platforming cost later is understood and budgeted.
• You are comfortable with a single-maintainer, low-adoption dependency (≈40 stars, zero dependent packages, MIT). You can pin the version, read the small Vue source, and fork into a private registry if the maintainer disappears. MIT makes the fork option real rather than theoretical — but only if someone has actually read the component.

Look elsewhere when:

• Rows need relational integrity: foreign keys, referential constraints, joins, uniqueness enforced by the database, or per-cell permissions. The field gives you none of that; a JSON blob plus a hand-written normalizer is not a substitute.
• Reporting, BI, or warehouse sync is a first-class requirement. Sorting and filtering Nova's index by a JSON attribute means orderByRaw with json_extract / -> operators that diverge between MySQL and Postgres. If sorting or filtering on these rows is a stated requirement, that is the signal to normalize — do not build a JSON-query layer you will throw away.
• The grid needs input types the component does not ship. Supported column types are whatever the Vue component implements. A date picker, formatted currency input, or dependent dropdown that isn't there means editing vendor/ or forking; price that in during the spike.
• You are not on Nova. Don't adopt a licence to adopt a field.
• You need per-cell validation feedback that survives a failed submit. Validation failures can cost the user their grid state (rows vanishing on a 422). Verify in a real browser — add three rows, break a rule in row two, submit — before committing to it as an ops surface.
• The data is customer-facing or high-volume. Different risk profile: audit, permissions, concurrency, and performance all need real answers.

Adoption gate checklist. Before committing, the PM should be able to answer yes to: one named real grid exists to build first (not a hypothetical); a nullable json column plus array cast is acceptable as the system of record; a normalizer/observer and max:N row guard rails will be written (the field will happily accept a mis-paste of thousands of rows); a rate_card_version column or _v key will exist from day one; the field will be onlyOnForms()/hideFromIndex() with a purpose-built read view beside it; the version is pinned in composer.json and the Nova/PHP matrix is recorded in the ADR; and the JSON → relational exit plan (normalizer + DTO + schema version) is named even if it never runs.

How to Pitch It (Stakeholders)

For executives (one paragraph): We already pay for Laravel Nova to run our admin panel. This is a free, MIT-licensed field that adds a spreadsheet-style editor to it, so ops can maintain things like rate cards, tax tables, and discount tiers themselves instead of filing engineering tickets. Backlog items that would have been "build a small admin screen" — days of engineering — become config changes measured in hours. The trade-off is real and worth stating: the data lands in a JSON column rather than a normalized table, which is fine while it's small, admin-edited, and only viewed in Nova, and we will keep the exit path open so a later move to proper tables is a migration, not a rewrite. The main risk is dependency risk: it's a small, single-maintainer package, so we pin the version and can fork it if needed.

For engineering (the ask): Spike it in an afternoon. Read the small source in vendor/ before designing a schema around guessed API — the field class and its chainable methods are the documentation. Pick one real grid, add a nullable json column with an array cast, register the field, save one row, and confirm the shape in tinker ([['region' => 'eu', ...]], not [{"0": ...}]). Then harden it: normalize on save in a model observer (filter() + values() — never trust the browser payload, blank rows reach the server), validate with wildcards in Resource::rules() including an max:N row cap, seed defaults so the first edit isn't a blank grid, hide the raw blob outside forms with onlyOnForms()/hideFromIndex() and pair it with a Text field displayUsing a formatted read view, expose a DTO instead of the raw column, version the stored shape, and feature-test the resource endpoint round trip rather than the Vue widget. Field-level permissions (canSee, readonly) are cheap — use them to keep the grid away from users who shouldn't edit business rules. Pin the version without a caret for the first release, note Nova/PHP in the ADR, and add a CI branch that bumps Nova so breakage surfaces before an unrelated upgrade causes it. Budget the exit: the realistic regret case is finance wanting these rows in the warehouse, so keep the normalizer, DTO, and schema version in place from day one.

The one-line version: already have Nova? This turns a days-long admin CRUD build into an afternoon of config — as long as we treat the JSON as a deliberate, documented, exit-planned choice rather than an accident.