Html Laravel Package

Getting Started

Install the package and let Laravel's package discovery register the service provider:

composer require styde/html
php artisan vendor:publish --provider="Styde\Html\HtmlServiceProvider"

Look first at config/html.php — it controls which theme (Bootstrap 3 by default) is used to render fields, alerts and menus. Then open vendor/styde/html/src/ and read Html.php, FormField.php and the Theme/ directory; that is the whole surface area of the package.

The fastest first use case is rendering a labelled form field and an alert in a Blade view. Import the facade alias Html (or reference Styde\Html\Facades\Html directly):

{!! Html::alert('Your profile has been updated', 'success', true) !!}

{!! Html::field('text', 'name', 'Full name', old('name'), ['class' => 'form-control']) !!}

Both calls return renderable objects, so they are echoed with {!! !!} rather than {{ }}. Once this works, you have proven the theme, the config and the facade wiring in one step.

Implementation Patterns

Form fields as reusable units. Html::field($type, $name, $label, $value, $options) returns a FormField object. Use the fluent methods on it for the repeated bits — ->required(), ->readonly(), ->help('Enter your legal name') — and pass a $errors object in so the theme can attach has-error classes:

{!! Html::field('email', 'email', 'Email', old('email'))
        ->required()
        ->help('We never share this address') !!}

For a whole form, Html::fields([...]) accepts an array of field definitions and renders them in order, which keeps your Blade files declarative instead of full of per-element markup.

Menus with active-state detection. The menu builder is the feature you will reach for most. Define items with route or url keys and let the package compare against the current request to add the active class:

{!! Html::menu([
    'home'    => ['route' => 'home',      'text' => 'Home'],
    'reports' => ['route' => 'reports.index', 'text' => 'Reports'],
    'docs'    => ['url' => 'https://example.com/docs', 'text' => 'Docs'],
]) !!}

Keep the definition in a view composer or a dedicated partial (resources/views/partials/nav.blade.php) so route names live in one place.

Links. Html::linkRoute('users.show', 'View', $user) and Html::linkAction(...) save you from route() plus manual anchor markup, and they respect the configured theme's button/icon conventions.

Wiring flash messages into alerts. The natural pattern is a single partial rendered in your layout:

@foreach (['success', 'error', 'warning', 'info'] as $type)
    @if (session()->has($type))
        {!! Html::alert(session($type), $type, true) !!}
    @endif
@endforeach

Composition over direct calls. Because each call returns an object, wrap them in your own Blade components or partials (<x-form-field>) rather than scattering facade calls. That way, when you swap the theme or drop the package, you only edit one file.

Gotchas and Tips

The package is dormant. The last release was March 2019 and there are no dependents. Treat it as vendored code you own. On modern Laravel you should verify it installs and that the facade alias and service provider still resolve; older packages frequently rely on the global str_*/array_* helpers, so add laravel/helpers if you hit undefined-function errors.

Everything bypasses escaping. Output is raw HTML by design. Never pass user input as the label or as options without escaping it yourself; the $value of a text field is escaped by the theme, but attribute arrays are generally not sanitised.

CSRF and method spoofing are not automatic. Add @csrf and @method('PUT') inside your <form> tags as usual — the package builds fields, not full forms with hidden inputs.

Validation state is manual. has-error and inline error text only appear if you feed the field the validator/error bag. Decide early whether you render errors inside the field or in a separate block at the top of the form, and keep it consistent.

Active menu matching is route-name based. Nested resources (users.index vs users.show) may not light up the parent item unless the theme supports wildcards. If the built-in matching misbehaves, use a named route pattern for the item rather than expecting prefix logic to be inferred.

Theme overrides. The default templates live in the package's Theme classes/views. Publish them into your app before editing — otherwise composer update silently reverts your tweaks, and you will not have a diff to review.

Config caching. After changing config/html.php, run php artisan config:clear in development. A cached config also means dynamically swapping the theme at runtime (e.g. per-tenant styling) will not behave as expected.

Debugging odd output. If a field renders empty or unstyled, dump the object with {{ dump(Html::field(...)) }} before echoing it — the fluent methods return $this, so a misplaced semicolon or a call on the return of ->render() is the usual culprit.

Exit plan. Given the maintenance risk, isolate usage behind your own helpers or Blade components from day one. The migration to plain Blade plus a small macro is straightforward, and having the seam in place makes that a one-afternoon change instead of a project-wide refactor.