Nova Inline Relationship Laravel Package

Getting Started

This is a small, low-adoption package (0 stars, 0 dependents) that gives you an InlineRelationship field for Nova resources. It flattens a related model’s attributes into the parent resource’s index/detail views so you don’t have to click into a related resource just to read a couple of columns. Treat it as a display convenience, not a full relationship-field replacement.

Minimal steps:

composer require igrik/nova-inline-relationship

• Laravel auto-discovery should register the service provider; if you’re on an older Nova/Laravel combination, check composer.json for a providers/aliases block.
• Verify Nova version compatibility first (the package was built against a specific Nova major line). Run composer why-not laravel/nova after install to confirm it didn’t force anything.
• Where to look first: open vendor/igrik/nova-inline-relationship/src/ and read the InlineRelationship class. With a package this small and undocumented, the source is the documentation — confirm the field API (fields(), make() argument order, supported relationship types) before writing resource code.
• First use case: a BelongsTo/HasOne you display on the index — e.g. an Order resource showing the customer’s name and email without an extra resource click.

use Igrik\NovaInlineRelationship\InlineRelationship;

public function fields(Request $request)
{
    return [
        InlineRelationship::make('Customer')
            ->fields([
                Text::make('Name', 'name'),
                Text::make('Email', 'email'),
            ]),
    ];
}

Implementation Patterns

Display-only on index/detail (recommended). Use the field where you need read access to related attributes. Keep the relationship declared normally on the model (customer()), and eager load it in indexQuery/detailQuery to avoid N+1.

public static function indexQuery(NovaRequest $request, $query)
{
    return $query->with('customer');
}

Mirroring a related resource’s fields. Define the inline fields to match the related resource’s fields(), but keep them minimal — just what belongs on the parent screen. Don’t drag in every related field; that’s what the relationship link is for.

Panels/groups for readability. Wrap the inline field in the same layout primitives you use elsewhere (Panels\Panel, Field::make(...)->rules(...) grouping) so visually it doesn’t look like a floating block of unrelated fields.

Guarding against missing relations. Related records can be null. If the package doesn’t handle it gracefully, resolve defensively in the field setup (e.g. ->hideIf(...) or a resolveUsing/displayUsing callback) so an empty relation doesn’t blow up the index.

Form usage — be conservative. If the field supports writing back through the relationship, test it hard: create, update, validation failure, and partial payloads. If it’s display-only in practice, pair it with the normal Nova relationship field for editing so you don’t end up with an unvalidated side-channel writing to a related model.

Migration note. Nova 4+ has native tooling for this kind of flattening (relationship fields, computed fields, BelongsTo display callbacks). If you’re on Nova 4, consider BelongsTo::make(...)->displayUsing(...) or a computed field first and only reach for this package if it saves meaningful boilerplate.

Gotchas and Tips

• N+1 is the default failure mode. Every inline attribute resolves through the relationship; if it isn’t eager loaded in indexQuery, an index of 50 rows becomes 50+ queries. Always check with DB::listen or Telescope.
• No sorting/filtering on inline columns. The inline attributes aren’t real database columns on the parent query, so sortable() and filters won’t work unless the package explicitly joins them (unlikely for a package this size). Don’t expose them as sortable headers.
• Index search won’t find them. Nova’s global search hits the resource’s own columns; related attributes are invisible to it.
• Relationship type support is narrow. Expect singular relations (BelongsTo, HasOne, MorphOne) to work; HasMany/BelongsToMany/MorphMany are usually not rendered as inline cells. Verify in the source before designing a screen around it.
• Version drift. With 0 stars and no dependents, this is effectively unmaintained for your Nova version. Pin the package version in composer.json and add an integration smoke test (index + detail + form) so a Nova upgrade doesn’t silently break rendering.
• Debugging: dump the resolved field in a tinker session ((new YourResource)->fields(request())) to see what attributes the field actually asks for, and inspect the compiled Vue assets in dist/ if the front-end rendering looks wrong — a stale dist is a common cause.
• Extension points: the field is a standard Nova Field subclass, so resolveUsing, displayUsing, onlyOnIndex/onlyOnDetail, canSee, and hideWhenUpdating all apply normally. Use them to scope the field to read contexts.
• Don’t rely on it for authorization. Inline attributes bypass the related resource’s authorizedToView policies. If the related data is sensitive, gate the inline field itself with canSee and a policy check.