Getting Started

Install the package with Composer and publish its config/assets as described in its service provider (vendor:publish). Run any migrations if the package ships form/field persistence.
First place to look is the config file (field registry, defaults, autofill source config) and the field class directory. Field types are the core abstraction, so skim the base field class and one concrete field (e.g. the autofill field) before writing your own.
Fastest first use case: build a small form schema using a couple of built-in fields, then swap one for the autofill field to see how suggestions are sourced, searched, and rendered.
v0.5.14 adds a checkboxes field, so if your first form needs multi-select, reach for it directly instead of hand-rolling a Blade loop over checkboxes. Checkboxes submits an array of selected values, which pairs naturally with array validation rules.

Implementation Patterns

Schema-driven forms: define fields as objects/classes in your form definition rather than raw Blade. This keeps validation, labels, defaults, and rendering in one place and makes the field types (autofill, checkboxes, text) interchangeable.
Autofill field usage: configure the source (model query / API) and the search key. Since v0.5.14, autofill results are capped at 50, so design UX around a filtered search box rather than expecting full result sets. For large datasets, add server-side search terms and let the 50-cap act as display guardrail.
Checkboxes field usage: pass an options array (or label/value map), set a default array, and validate with array + in:/exists: rules. Bind the submitted array back to a pivot or JSON column as needed.
Composition workflow: keep custom fields in app/Fields or a dedicated namespace and register them via the package's field registry/config. Prefer wrapping shared behavior in a base class so checkboxes and autofill both inherit your validation and rendering conventions.
Integration tips: pair field config with Laravel validation rules (the package may generate them, but explicit rules are safer). Use Livewire/Inertia event hooks if the form is reactive — autofill search especially benefits from debounced updates.

The 50-result cap on autofill is a hard limit, not a suggestion. If users expect to browse a full list, you need a dedicated search/pagination field or fetch path; otherwise the 50th+ match silently drops. Surface this in UX copy so users know to type more.
Checkboxes values are arrays. Guard against empty submissions ([] vs missing key), and make sure your default value is an array, not a scalar — a common cause of "0 selected" bugs.
Autofill debugging: log the resolved source query and the applied limit; if suggestions look truncated at 50, that's the new behavior working as intended. Check whether your search term is actually being passed through rather than ignored.
Validation drift: if the package auto-derives rules from field config, audit them for checkboxes (array, each value allowed) and autofill (value must exist in source). Custom fields often need explicit rules.
Extension points: register custom field classes via the config registry rather than editing vendor code; override the package's views by publishing them and pointing to your own namespace. This survives future releases better than patching in place.
Version pinning: this is a pre-1.0 package (v0.5.x), so minor bumps can change behavior (as the autofill cap shows). Pin a version range and read release notes before upgrading in production.