Nova Creatable Belongs To Laravel Package

Getting Started

• Install with Composer: composer require sparclex/nova-creatable-belongs-to. No service provider registration or config publish is required — it's a Nova field, not a package with runtime bootstrapping.
• Open the related Nova resource first. This field renders the related resource's fields() method inside a creation modal, so the modal experience is only as good as the resource definition you're pointing at. If Category has panels, file uploads, or relationship chains that don't make sense in a 400px modal, fix that resource before wiring the field.
• The first use case is the canonical one: Post belongs to Category, and editors are tired of leaving the post form to create a missing category. In app/Nova/Post.php, swap BelongsTo::make('Category') for the package's field and keep everything else identical — it's a drop-in replacement.
• Verify authorization before anything else. The "create" affordance is gated by the related resource's Nova policy (create ability). Log in as a non-admin and confirm the option disappears, because the most common first bug report is "the create button doesn't show" and the answer is almost always a policy, not the field.

Implementation Patterns

• Drop-in BelongsTo subclass. Because the field extends Nova's BelongsTo, every modifier you already use keeps working: searchable(), nullable(), rules(), withMeta(), relatableQueryUsing(), dependsOn(). Use it as a straight substitution rather than wrapping it in custom logic.
• Inline creation for lookup tables. The sweet spot is short, low-cardinality resources with simple fields: categories, tags, authors, teams, warehouses, cost centres. Keep the related resource's form to a handful of text inputs so the modal stays usable.
• Policy-aware UX. Rely on create policies to control exposure rather than conditionally building the field list. If you need to restrict which resources can be created inline, do it in the policy or via relatableQueryUsing() on the parent query, not by branching resource fields() methods.
• Pair with searchable(). On any resource with more than a few dozen rows, the select is unusable without it, and Nova's search endpoint is what the field's lookup uses. Combined with relatableQueryUsing(), you get scoped search (e.g. only categories for the current tenant) plus inline creation in one control.
• Validation lives on the related resource. Since the modal posts to Nova's standard resource store endpoint, the rules() on the related resource's fields are what run. Duplicate this validation in the parent resource only if you also need it for the selected (not created) case.
• Keep it out of nested/relationship-heavy contexts. If the parent resource is itself being edited inside a HasMany inline form or a dependent field chain, prefer a plain BelongsTo. Modals inside modals inside repeatable fields are where this field degrades.

Gotchas and Tips

• Check your Nova version before adopting. Nova 4+ ships BelongsTo::showCreateRelationButton(), which covers the same ground for many teams. If you're on Nova 4, prototype with the built-in first; adopt this package only if you specifically need its UX. With 14 stars, you're taking on a small-supply-chain dependency — pin the version in composer.json and be ready to fork.
• The create button disappearing is nearly always authorization. Confirm the create method on the related resource's policy returns true for the logged-in user. Debug in the browser network tab, not in Blade.
• The modal renders the target resource's real fields. File uploads, BelongsTo fields pointing elsewhere, panels with computed metrics — all of it shows up. If your target resource is heavy, consider a dedicated lightweight Nova resource (or conditional fields() based on $request->isMethod('post') / context) purely for creation.
• Dependent fields and dependsOn won't chain inside the modal. The modal has no access to the parent form's state, so any field in the related resource that depends on the parent form's values will render empty or uninitialized. Design the related resource so its creation form is self-contained.
• Custom store behaviour is bypassed in spirit. If the related resource has a custom store controller with side effects (slugs, notifications, attaching tenants), those still run because it hits the standard endpoint — verify it, because people often assume modal creation skips them. The failure mode is a record created without the tenant/user scoping your controller normally applies.
• Validation errors surface as raw Nova field errors in the modal, and they'll reference the related resource's attribute names. That's correct behaviour but confuses users who see "name is required" while filling in a Post form. Label your related resource fields clearly.
• Extension point: override the field's meta via withMeta() or subclass the field to adjust the modal's labels. There's no config file, so subclassing is the supported escape hatch for anything the README doesn't expose.
• Test it with Dusk, not unit tests. The behaviour is JavaScript-driven DOM interaction; a Laravel feature test posting to the API proves nothing about whether the create option renders. One Dusk test that opens a post, creates an inline category, and saves the post is worth ten unit tests here.