Nova Resource Field Laravel Package

Getting Started

advoor/nova-resource-field is a Laravel Nova field that embeds a related Eloquent resource's management UI (list/create/edit) directly inside another resource's form. It saves you building bespoke relation managers or nested forms for the common "edit this parent, and tweak its children on the same screen" workflow.

1. Install:

   composer require advoor/nova-resource-field
   php artisan nova:publish   # if the package ships assets/config
   

2. Read first: the README's field-options table and the src/ field class. On a package this small, the field class is the source of truth for which fluent setters actually exist — the docs tend to lag behind releases (v0.3 is a good example: per-field settings landed before many users will notice it in the docs).
3. First use case: add the field to an existing resource that already has a HasMany/BelongsToMany relation you currently manage with a separate resource. Drop the field in, point it at the related resource, remove the standalone nav entry for the child resource, and you have an inline CRUD surface in one sitting.

public function fields(NovaRequest $request)
{
    return [
        Text::make('Name'),
        NovaResourceField::make('Line Items')
            ->resource(\App\Nova\LineItem::class),
    ];
}

Implementation Patterns

Per-field settings (new in v0.3). The headline change is that configuration can now be supplied per field instance rather than globally. This is the single biggest day-to-day improvement: previously, two fields on the same resource — say a compact "Line Items" grid on a parent and a full "Attachments" browser elsewhere — had to share package-level config or be forked.

NovaResourceField::make('Line Items')
    ->resource(\App\Nova\LineItem::class)
    ->settings([
        'perPage'    => 50,
        'compact'    => true,
        'hideSearch' => false,
    ]),

NovaResourceField::make('Attachments')
    ->resource(\App\Nova\Attachment::class)
    ->settings([
        'perPage'    => 10,
        'onlyView'   => true,
    ]),

Extract a field factory. Once you're passing settings arrays around, wrap repeated shapes in a private method or a small helper class so settings don't drift between resources:

private function lineItemsField(): NovaResourceField
{
    return NovaResourceField::make('Line Items')
        ->resource(LineItem::class)
        ->settings(config('shop.line_item_field'));
}

Keeping the array in config/ (or a NovaServiceProvider method) lets you vary behaviour per environment — e.g. read-only settings in staging.

Compose with standard Nova modifiers. Treat the field like any other: ->onlyOnDetail(), ->canSee(fn ($request) => $request->user()->can('updateLineItems', $this->resource)), ->help(). Authorization is the important one — the field exposes child-resource actions inside the parent form, and Nova's per-resource policies are enforced on the resulting requests, but hiding the field for unauthorised users gives a much cleaner UX than letting them hit a 403 after typing.

Settings as an extension point. The cleanest way to cover a one-off need is to check whether the behaviour can be expressed as a setting before subclassing. Subclassing the field is viable but you own the upgrade burden on every release, and this package is pre-1.0 — churn is likely.

Testing. Feature-test the parent resource's update endpoint rather than the field's rendering. Assert that a child created through the embedded UI persists and that a user without the child policy gets a 403 on the nested request.

Gotchas and Tips

• Settings must be serialisable. Per-field settings are passed through to the frontend (typically JSON), so closures, enums without JsonSerializable, and Eloquent models will break or silently arrive as {}. Convert to scalars/arrays before passing them in.
• Precedence is package-default → global config → per-field settings. When a per-field value doesn't take effect, confirm you aren't setting it globally in a published config that the field reads after your ->settings() call. php artisan config:clear and a nova:publish after upgrades catch most of these.
• Upgrading from v0.2 is non-breaking — the release only widens configuration. But if you previously worked around the lack of per-field config by duplicating the field class or by wrapping the component, unwind that workaround now; leaving both mechanisms in place makes the precedence chain genuinely hard to reason about later.
• Settings keys are not validated. A typo like 'perpage' is accepted and ignored, giving you a field that looks configured but isn't. Verify each key against the README (or the field class's default settings array) the first time you use it, and keep a smoke test that renders the parent form.
• Asset caching bites in production. If settings appear to be ignored only in prod, it's almost always stale compiled assets or an OPcache/config cache — not the field. php artisan optimize:clear before digging into the source.
• Nova major-version compatibility is the real risk. Check the package's composer.json Nova constraint against your installed version before planning upgrades; this package's small surface makes it easy to patch locally if needed, but a Nova upgrade will usually be the thing that breaks it.
• Watch the issue tracker for settings semantics. With per-field config newly landed, expect follow-up releases adding keys. Pin a minor version in composer.json if you're shipping close to a deadline.