Sexy Field Field Types Base Laravel Package

Getting Started

1. Install

   composer require tardigrades/sexy-field-field-types-base
   

   This is a low-traffic, single-maintainer package — pin it to an exact version (:"x.y.z") until you've validated it in your app, since tagged releases may move without broad community testing.

2. Where to look first

   • src/ — the list of concrete field types (expect basic primitives: text, textarea, checkbox, radio, select, hidden, maybe submit/button).
   • The abstract base class each type extends — this is the contract that defines what you can override (view(), rules(), attributes(), toArray()/render() — names vary, read the source).
   • resources/views/ if views ship with the package — those show the expected data shape passed to Blade.
   • composer.json — check the illuminate/* constraints against your Laravel version before installing; this is the most common break point for small packages.
   • README / tests — a near-zero-star package often has thin docs, so the test suite is your real spec.

3. First use case Instantiate a base type inside a form definition and render it:

   use Tardigrades\SexyField\FieldTypes\Base\Text;
   
   $field = new Text('email', [
       'label' => 'Email address',
       'rules' => ['required', 'email'],
   ]);
   

   Then wire it into whatever field registry/container sexy-field expects (the base package provides the types, not the renderer or the builder). Read the parent sexy-field package's docs to see how types are registered and rendered — this package is explicitly a leaf dependency.

Implementation Patterns

Extending a base type for a custom control. The intended usage is inheritance, not direct instantiation. Most "field types base" packages exist so you can subclass a working primitive and change one dimension (view, validation, attribute mapping) without rebuilding plumbing:

class Phone extends Text
{
    protected function defaultRules(): array
    {
        return array_merge(parent::defaultRules(), ['regex:/^\+?[0-9 ()-]+$/']);
    }

    public function view(): string
    {
        return 'fields.phone'; // your Blade view
    }
}

Registration through a registry / config. If the package ships a config array or registry service, register your subclasses alongside the built-ins rather than editing vendor files. Typical shape:

// config/sexy-field.php (or a ServiceProvider)
'types' => [
    'text'     => \Tardigrades\SexyField\FieldTypes\Base\Text::class,
    'textarea' => \Tardigrades\SexyField\FieldTypes\Base\Textarea::class,
    'phone'    => \App\Fields\Phone::class,
],

Map field types to Laravel validation. The common integration is passing the field's rules() output straight into a form request or Validator::make(). Keep rules on the field type (so they travel with the field) and merge request-level rules on top.

Compose instead of subclassing when only the view changes. If you just want Tailwind rendering of a stock text input, subclassing or overriding a view in a config map is much cheaper than creating a new type per view. Reserve subclassing for changed behaviour (rules, casting, hydration), not changed markup.

Factory/decorator for reuse. Wrap type construction in a small factory so you control defaults in one place:

class Fields {
    public static function text(string $name, array $attrs = []): Text {
        return new Text($name, $attrs + ['class' => 'form-input']);
    }
}

Testing your field types. Instantiate the type directly and assert on toArray()/render() output. Because this package has essentially no consumer base, your tests are what protect you on upgrades — write at least one per subclass asserting the rules array and the rendered attributes.

Use as the base for a custom design system. The package's own description says these types are "the base for more advanced setups" — the intended architecture is: this package = primitives; your app (or a second package) = design-system types that extend them. Keep that boundary, or vendor coupling grows fast.

Gotchas and Tips

• Package discovery: Small packages often omit a ServiceProvider or forget to register it in extra.laravel.providers. Check composer.json's extra block; if empty, plan to register a provider manually in config/app.php (Laravel <11) or bootstrap/providers.php (Laravel ≥11).
• Laravel version constraints are the first failure. Before adopting, read composer.json's illuminate/* or laravel/framework requirement and compare with your installed version. A near-zero-star package is unlikely to have been bumped for recent Laravel releases — expect to composer update or run a fork if the constraint is stale.
• Don't rely on the README. With 0 dependents there's no community signal for what's safe to override; the abstract base class's protected/public method signature is the API. When you subclass, override only what's protected and leave constructor signatures intact.
• Namespace collisions. The Tardigrades\SexyField\... namespace is unusual — check for case/PSR-4 mismatches on case-sensitive filesystems (Linux CI) even if it works on macOS. A composer dump-autoload and case audit solves 90% of "class not found" reports on small packages.
• View resolution order. If views ship in the package, publish them (php artisan vendor:publish --tag=...) before overriding. Overriding an unpublished view path is the most common silent failure — the package view wins and your changes never render.
• Attribute merging. If attributes()/toArray() use array_merge, user-supplied attributes usually win, but class merging (string vs array) is a frequent break. Decide on one convention and enforce it in your subclasses.
• Validation coupling. Keep rules() returning an array of strings rather than Laravel rule objects — it composes with Validator and form requests, and avoids breaking when Laravel changes Rule internals.
• Extension points to prefer: (1) subclass the base type, (2) override the view map in config, (3) add a custom type to the registry. Avoid editing vendor/ — a composer update on a package with no dependents may silently change internal method names in a patch release.
• Debugging tip: var_dump($field->toArray()) (or your package's serialization equivalent) before rendering — most bugs are attribute shape mismatches, not template logic.
• Forking plan. Given the low maintenance signal (0 stars, 0 dependents), have a contingency: fork to app/FieldTypes/ behind a thin interface your app owns, so a dropped dependency is a config change, not a rewrite.