Nova Dni Field Laravel Package

Getting Started

Install the package with Composer and confirm the Nova version constraint in its composer.json before adopting it:

composer require r64/nova-dni-field

Look first at:

• The package README for the exact field namespace and usage.
• src/ for the field class and any validation rule. The field is commonly referenced as R64\NovaDniField\Dni, but confirm against the installed version.
• composer.json for Laravel/Nova/PHP compatibility.
• Any service provider or published asset instructions. Some Nova fields need php artisan nova:publish or an asset rebuild.

Add the field to a Nova resource:

use R64\NovaDniField\Dni;

public function fields(Request $request)
{
    return [
        Dni::make('DNI', 'dni')
            ->rules('required', 'max:20'),
    ];
}

First use case: a customer or company resource where Spanish individuals use DNI/NIE and companies use NIF/CIF. Use the field on create/edit forms so invalid tax identifiers are rejected before they reach your database, then add the same validation to imports and APIs.

Implementation Patterns

Use the field as the Nova UI, but keep validation reusable. If the package exposes a validation rule, use it in both Nova fields and application-level FormRequest or API validation. If it only provides the field, wrap the same logic in a custom rule so imports, APIs, and Nova do not drift.

Dni::make('DNI', 'dni')
    ->rules('required', 'max:20')
    ->help('DNI/NIE for individuals; NIF/CIF for companies.');

Normalize before validation. Spanish identifiers are often entered with spaces, hyphens, or lowercase letters. Normalize in a model mutator or field callback rather than allowing inconsistent stored values:

public function setDniAttribute($value): void
{
    $this->attributes['dni'] = strtoupper(preg_replace('/[\s-]+/', '', $value ?? ''));
}

Handle uniqueness with Nova creation/update rules. A tax ID is usually unique per customer or company. Use Nova’s creation/update rule hooks or placeholder-aware rules so editing a record does not falsely collide with itself:

Dni::make('DNI', 'dni')
    ->creationRules('unique:customers,dni')
    ->updateRules('unique:customers,dni,{{resourceId}}');

Reuse the identifier rule outside Nova. Imports, CSV uploads, onboarding APIs, and admin commands should share the same validation. Create an app-level SpanishTaxId rule and call it from Nova, form requests, and queue jobs. This is especially important because Nova validation alone does not protect non-Nova entry points.

Store canonical values. Use a string column such as varchar(20), store uppercase without separators, and index it if you look customers up by tax ID. Avoid integers because leading zeros and letters are significant.

Use standard Nova field methods for display. You can still use hideFromIndex, sortable, help, resolveUsing, or displayUsing where appropriate. Keep the raw canonical value in the database and format only for presentation.

Gotchas and Tips

• Check Nova compatibility early. This is a small, low-adoption package. Verify it works with your Nova major version, Laravel version, and PHP version. Pin the version and cover the field with a smoke test before relying on it.
• Do not assume “DNI” means only DNI. The package targets Spanish DNI/NIF/CIF, but you must verify which formats and checksum rules it actually accepts. Test DNI, NIE, NIF, and CIF examples, including invalid control letters.
• Normalize before validation, not after. If you uppercase or strip separators only in the database mutator, Nova may validate the raw user input and reject values that would have been valid after normalization. Normalize in the request path or field callback before the rule runs.
• Watch client-side versus server-side behavior. Nova’s validation is ultimately server-side, but browser formatting can mislead users. Add help text showing expected formats and test with lowercase, spaces, and hyphens.
• Missing assets render confusing fields. If the field appears blank or unstyled, check whether package assets were published, whether nova:publish was run, and whether the browser console shows a missing component. Clear Nova/Laravel caches after publishing.
• Unique rules need care. Use Nova’s placeholder patterns for update rules and account for soft deletes if your table uses them. Test create and edit paths separately.
• Debug with real values. If validation fails unexpectedly, dump the normalized value immediately before validation and run the same value through the package rule in php artisan tinker. Compare against a known-good checksum implementation.
• Extension points are your safety net. Prefer a model mutator/accessor, an app-level validation rule, and resolveUsing/displayUsing over modifying vendor code. If the package’s field component is too limited, create a thin local field class extending it and override the component or rules.
• Treat the package as a UI convenience, not your only safeguard. Because it has few stars and no dependents, keep the validation logic tested in your application and be prepared to replace the field with a local implementation if maintenance stops.