Nova Color Field Laravel Package

Getting Started

djstarcom/nova-color-field is a Laravel Nova form field for selecting and displaying colors. Start in a Laravel app that already has Nova installed:

1. Install the package:

composer require djstarcom/nova-color-field

2. Add a string column to the model’s table and migrate:

$table->string('brand_color')->nullable();

3. In the Nova resource, import the package’s Color field and add it to fields():

use DJStarCOM\NovaColorField\Color;

public function fields(NovaRequest $request)
{
    return [
        Color::make('Brand Color', 'brand_color')
            ->rules('required', 'string', 'max:32')
            ->help('Choose the brand color used in the UI.'),
    ];
}

First use case: a nullable brand/accent color on a settings, team, or profile resource, edited through Nova and stored as a normal string column.

Where to look first: the package README and vendor/djstarcom/nova-color-field, then the Nova resource’s fields() method and the migration column. For the 3.0 upgrade, read the linked changelog before changing constraints.

Implementation Patterns

• Treat the field as a Nova form control, not a full color-management system. Persist the value in a normal string column and keep formatting rules explicit.
• Use standard Nova field methods for day-to-day behavior: rules, nullable, default, help, hideFromIndex, onlyOnForms, and readonly where appropriate.
• Add server-side validation for the stored format. If you accept hex only, validate with a regex; if you accept rgba()/rgb(), allow enough column length and validate that format.
• Normalize at the boundary if multiple entry points exist: Nova, API, imports, and seeders should all write the same format.
• Use a model mutator/accessor or Nova resolveUsing/fillUsing if you need a canonical stored value, such as lowercase six-digit hex.
• For index/detail views, use the field’s preview where useful; otherwise hide it from index and show it only on forms/detail to keep tables compact.
• Use default('#ffffff') or a model-level default for new records, but still validate because defaults do not guarantee valid user input.
• Keep color presets or palette choices in application code or a custom field wrapper rather than scattering magic strings across resources.
• When seeding or importing, write the same normalized format the Nova field expects.

Gotchas and Tips

• 3.0 is a major release and the provided release note is only a changelog link. Treat it as an upgrade checkpoint: read the changelog, check composer.json constraints for PHP/Laravel/Nova compatibility, and test on staging before rolling to production.
• If the field does not render, first verify Nova asset publishing and caches: php artisan nova:publish, php artisan optimize:clear, and composer dump-autoload.
• Do not rely on the browser picker for validation. Validate and normalize on the server; clients can submit arbitrary strings.
• Choose the database column size based on accepted formats. Hex is short, but rgba(...) values need more room.
• Be consistent about alpha/opacity. If the field outputs a format your API or CSS cannot consume, normalize it before storage or before output.
• Check whether the field returns null for empty values and make the column nullable if that is intended.
• For debugging, inspect the raw Nova request payload and the stored model attribute. That quickly separates picker/UI issues from persistence/validation issues.
• Extension point: wrap the package field in your own Nova field class or model accessor if you need organization-wide color rules, presets, or a different stored format.