Nova Split Date Input Laravel Package

Getting Started

mimosu/nova-split-date-input is a Laravel Nova custom field that replaces the standard date picker with separate day / month / year inputs, while still persisting a single date value to your model. v1.0.0 is the initial tagged release, so there is no migration path to worry about — but the release notes contain only a changelog link, so treat the repository (src/, resources/js/, composer.json) as the source of truth before adopting.

1. Install into the Nova app (not a standalone one):

   composer require mimosu/nova-split-date-input
   

2. Check the Nova version constraint in the package's composer.json against your installed laravel/nova major. Custom fields are tightly coupled to Nova's frontend toolchain; a mismatch usually surfaces as a field that renders nothing or throws in the browser console.
3. Compile/publish assets if required. If the package ships uncompiled JS, run the package build (npm install && npm run prod) and php artisan nova:publish. If it ships a compiled dist/js/field.js, this step is a no-op.
4. Wire it into a resource — the fastest sanity check is a date-of-birth style field:

   use Mimosu\NovaSplitDateInput\SplitDate; // confirm namespace in src/
   
   public function fields(NovaRequest $request)
   {
       return [
           SplitDate::make('Birthday')
               ->rules('nullable', 'date'),
       ];
   }
   

5. First use case: date of birth, passport/ID expiry, or any form where users type dates from paper documents and a datepicker is slower than three boxes.

If the field doesn't appear at all, the problem is almost always asset compilation, not PHP.

Implementation Patterns

Basic resource usage. Treat it as a normal Nova field — everything on Laravel\Nova\Fields\Field (->nullable(), ->rules(), ->sortable(), ->hideFromIndex(), ->help()) applies, because the split UI is a presentation concern over one underlying attribute.

Model side stays conventional. Cast the column normally so the rest of your app is unaffected:

protected $casts = [
    'birthday' => 'date:Y-m-d',
];

The field should round-trip a Y-m-d string. Keep the DB column a date (or string if you deliberately store partial dates) — the split input is not a reason to change your schema.

Validation lives on the parent field. Attach rules to the field itself rather than trying to validate three sub-inputs:

SplitDate::make('Birthday')
    ->rules('required', 'date', 'before:today')
    ->messages(['before' => 'Birthday must be in the past.']);

Remember date accepts 2024-02-31 in some PHP versions only loosely — add date_format:Y-m-d if you need strictness.

Display formatting for index/detail. Use Nova's standard helpers so the split UI only applies to forms:

SplitDate::make('Birthday')
    ->displayUsing(fn ($value) => $value?->format('d M Y'))
    ->onlyOnForms(); // or ->hideFromIndex()

Reuse across resources. Subclass the field once in your app (App\Nova\Fields\Birthday extends SplitDate) and bake in rules, formatting, and default order there. This keeps ~10 resources consistent and gives you a single place to patch if the underlying package needs a fix.

Filters and sorting work against the raw column, not the three sub-inputs — nothing special is needed, but only enable ->sortable() if the column is actually a sortable date/string, not a JSON blob.

Customising persistence. If your column format differs (e.g. d/m/Y legacy data), override resolveUsing / fillUsing on a subclass rather than post-processing in the model, so the transformation stays scoped to the Nova layer.

Gotchas and Tips

• Empty vs null. Three blank inputs can serialise to '', null, or even 0000-00-00 depending on how the field's fill hydrates. Always pair the field with ->nullable() plus a nullable rule, and test clearing an existing value on an update form — this is the single most common bug with split date fields.
• Partial input. Users will fill the year and skip the month. Decide up front whether that is a validation error (required + date) or a legitimate partial date (store as string). Don't leave it to chance.
• Timezone drift. Nova serialises dates through Carbon in a few places. If a birthday shifts by one day for users in negative UTC offsets, you're seeing a date value parsed as midnight UTC then displayed in local time — fix with an explicit date:Y-m-d cast and displayUsing formatting that ignores timezone.
• Assets are the #1 failure mode. Field renders blank / console shows a missing component → check nova:publish, check whether dist/js/field.js exists in the package, and confirm nova.mix.js was used for the build. Re-run npm run prod after any package update.
• Nova major compatibility. v1.0.0 is a first release; pin it in composer.json and re-test on every Nova upgrade. A field built for Nova 4's Field contract may need changes for Nova 5.
• Debugging payloads. Open the browser network tab and inspect the create/update request body — you'll immediately see what string the field submits, which answers most "why is it saving wrong" questions faster than reading the Vue source.
• Validation error placement. Errors attach to the parent field name, not to birthday_day. If you've hand-rolled separate _day/_month/_year attributes elsewhere, don't mix the two approaches on one form.
• Extension points: subclass the field for fillUsing/resolveUsing, use ->help()/->stacked() to control label layout (three boxes need horizontal room — test on a narrow viewport), and check for a publishable config/view before patching vendor code.
• Sparse release notes. v1.0.0's notes are only a changelog link. Before relying on it in production, skim the commit history and open issues for known limitations, and pin the exact version — expect breaking changes in early 1.x tags for a package this young.