Dash Ui Laravel Package

Getting Started

Pull the package in with Composer and let its installer publish the front-end scaffolding:

composer require combindma/dash-ui
php artisan dash-ui:install

The install command is the important step — it publishes the compiled CSS/JS entry points, the config file, and (optionally) the Blade views. If you skip it you'll get unstyled markup because the package ships its styles as a publishable asset rather than shipping a runtime CDN link.

From there, wire the published assets into your admin layout. In a Vite-based app you'll add the published CSS file to your app.css via an @import, and make sure Alpine.js is booted on the page (Dash UI's interactive components — modals, dropdowns, mobile menus, dark-mode toggle — expect Alpine to be present). If you're not using Vite, the install publishes a ready-to-link CSS file you can drop into your layout with a <link> tag.

Point Tailwind at the package views so utility classes inside the published Blade files survive purging:

// tailwind.config.js
content: [
  './resources/**/*.blade.php',
  './vendor/combindma/dash-ui/resources/views/**/*.blade.php',
],

Where to look first: the published config/dash-ui.php (component prefix, asset paths, defaults), then resources/views/vendor/dash-ui/ once you publish views — that's your source of truth for what markup each component renders and which Alpine directives it relies on.

First use case: build one real screen end-to-end rather than a component showcase. A settings page is ideal — it exercises a card wrapper, a form with validation states, a submit button, and an alert for the flash message. That single page will surface every integration issue (asset order, Alpine boot, Tailwind purge) in one sitting.

Implementation Patterns

Layout composition. Dash UI doesn't impose a full app shell, so the normal pattern is to build one admin layout (layouts/admin.blade.php) that loads your assets, includes the sidebar/topbar components, and leaves a {{ $slot }}. Every page then extends that layout and composes cards inside it. Keep the layout thin — a <x-dash-ui-sidebar> plus a content wrapper — and push page-specific chrome into the page itself.

Forms are where it earns its keep. The form components are designed to bind to old() and $errors automatically, which is the main day-to-day win:

<x-dash-ui-form action="{{ route('settings.update') }}" method="POST">
    <x-dash-ui-input name="site_name" :value="old('site_name', $settings->site_name)" label="Site name" />
    <x-dash-ui-select name="timezone" :options="$timezones" :selected="old('timezone', $settings->timezone)" />
    <x-dash-ui-checkbox name="maintenance" :checked="old('maintenance', $settings->maintenance)" />
    <x-dash-ui-button type="submit">Save</x-dash-ui-button>
</x-dash-ui-form>

Because the error rendering is baked into the input component, you avoid the repetitive <p class="text-red-500">{{ $errors->first(...) }}</p> boilerplate on every field. When a field needs custom validation display or a weird layout, reach for the base component and pass your own error slot rather than forking the published view.

Tables with pagination. The table component wraps your rows and pairs with Laravel's paginator links. The common pattern is a controller that paginates (->paginate(25)) and a view that passes $items plus a column definition via the table's slot. For anything with column-specific rendering (badges, action dropdowns, formatted dates), use per-cell slots rather than building the markup externally — it keeps the responsive table styling intact.

Modals and dropdowns via Alpine. These are Alpine-driven, so the trigger and the panel need to share state through x-data, or you use the component's built-in id/trigger conventions. The reliable workflow: let the component manage its own x-data scope, pass a unique id, and trigger via the companion button component. If you need a modal opened from JavaScript (e.g. after a failed fetch), set the shared Alpine state on a parent scope and bind the modal's show to it — don't try to toggle internal x-data you don't own.

Alerts and flash messaging. Pair a session flash with an alert component in your layout, and let it auto-dismiss by passing a timeout. This is a two-line addition to the layout that gives every controller redirect consistent feedback:

@if (session('status'))
    <x-dash-ui-alert type="success" :dismissible="true">{{ session('status') }}</x-dash-ui-alert>
@endif

Customisation workflow. Publish views only for components you actually need to change (php artisan vendor:publish --tag=dash-ui-views), then edit the published copies. Everything else continues to resolve to the package's originals, so you're not maintaining a full fork. Combine that with the config's component prefix to namespace Dash UI components if you also use another component library.

Gotchas and Tips

Tailwind purging is the number one "why is it broken" issue. If components render unstyled — usually after a production build but not in dev — your content globs don't include the vendor views, or you're using a Tailwind v4 setup and need @source instead. Verify by searching the compiled CSS for a class the package uses.

Alpine load order matters. Alpine must be booted before Dash UI's interactive components initialise, or you'll get unresponsive modals. If you're using Livewire, beware that Livewire bundles its own Alpine — loading a second copy produces silent breakage. Use the @livewireScripts Alpine and register the package's directives through it rather than a second <script src="alpine">.

Dark mode needs a matching strategy. The components are styled for both modes, but the toggle only flips a class. Make sure your Tailwind config uses darkMode: 'class' (the default the package assumes) and that the toggle writes the same class to <html>. If your app uses media strategy, the toggle will appear to do nothing.

The install command is not idempotent in the way you'd hope. Re-running it can overwrite customised published views. Treat published views as your code and run the installer once; when upgrading, publish to a scratch copy and diff rather than blasting over your edits.

Component prefix collisions. If you already have x-card or x-button from another package, your components silently shadow or get shadowed. Set the prefix in the config to something like dash and reference <x-dash-card> consistently — decide this on day one, because changing it later means touching every view.

Cache clearing after publish or config changes. Laravel caches Blade components and views aggressively. After publishing or editing the config you often need php artisan view:clear (and config:clear if you touched the config) before changes appear — this trips people up constantly when they edit a published view and see no difference.

Extension points: slots and attribute passthrough. Most Dash UI components forward arbitrary attributes (class, wire:model, x-on:*, data attributes) to the underlying element, so prefer attribute passthrough over forking a view for small tweaks. Reserve published-view edits for structural changes; one-off styling should be a class merge. Check individual components for named slots before assuming a base-component override is needed.

Don't fight the markup. The components are opinionated about spacing and structure. If you find yourself overriding half the utility classes on a card, you likely want the published view or a wrapper component — and that's a signal to publish that one view rather than accumulating !important-style overrides.