- How do I install and set up bastinald/laravel-livewire-loader?
- Install it with composer require bastinald/laravel-livewire-loader, then publish the package assets if it ships JS or CSS. Add the provided Blade include or directive to your root layout (or your Livewire layout template) so the spinner markup renders on every page. Most of the integration work is the layout edit, not the install itself. Confirm the spinner fires and clears on a simple component update before rolling it out.
- Which Livewire versions does this package support?
- That depends entirely on the Livewire constraint declared in the package's composer.json, so check it before committing. The package works by hooking Livewire's client-side lifecycle events, and those hook names changed between Livewire 2 and Livewire 3. An older or lightly maintained package is likely pinned to one major version. If your app runs Livewire 3 and the package targets Livewire 2, the spinner simply will not fire.
- Does laravel-livewire-loader work with Vite or does it require Laravel Mix?
- Many packages of this vintage assume Laravel Mix for asset delivery, which is the most likely friction point in a modern Vite app. If the published asset reference is Mix-era, you will need to re-plumb the JS into resources/js and import it through Vite. That is usually a small change but worth verifying in a branch spike. Vendoring the published JavaScript into your own asset pipeline avoids the issue entirely.
- Can I customize the spinner appearance or limit it to specific components?
- Configuration is the main unknown here, since many small loader packages ship a hard-coded global overlay with no delay, throttle, or markup options. Check whether a config file allows custom markup, a delay before showing, and per-component opt-out. If it is a strictly global overlay, you would need to fork or vendor the JS to scope it. Also verify accessibility basics such as aria-live announcements and prefers-reduced-motion handling, which small packages often skip.
- Does this conflict with Livewire's built-in wire:loading indicators?
- It does not technically conflict, since both observe the same Livewire request lifecycle, but you can end up with two competing loading affordances on the same screen. The global overlay fires on every request, while wire:loading is scoped to the element you attach it to. Pick one pattern per screen or you will get a flickering overlay and a local spinner at the same time. The global approach makes most sense on dashboards and CRUD screens where per-element indicators would be tedious to add.
- What happens to the spinner if a Livewire request fails or is aborted?
- This is one of the most important things to verify before shipping, because the classic failure mode is a spinner that sticks and blocks the UI. A well-behaved implementation clears the loading state in a message.processed style handler that runs on both success and failure. Test a deliberately failing component and a cancelled request to confirm the overlay disappears. If the overlay also sets pointer-events, a stuck spinner can make the page unclickable until refresh.
- Is bastinald/laravel-livewire-loader safe to use in production?
- The blast radius is low, but the vendor risk is real: a small star count, a single maintainer, and no visible CI signal suggest a hobby-scale project without semver discipline or support. The worst realistic failure is a spinner that flickers, sticks, or blocks clicks after a Livewire upgrade, which is recoverable but embarrassing. The package is functionally a few dozen lines of JavaScript, so replacing it in-house costs hours rather than weeks. Vendoring or snapshotting the published JS into your own asset pipeline is the pragmatic way to keep the convenience while removing the dependency risk.
- Will the loading overlay block clicks or appear above modals and toasts?
- That is the most common visual regression with global loading overlays. Check the overlay's z-index against your modal and toast layers, and confirm pointer-events are handled so users are not locked out during a slow request. A full-screen overlay above a Bootstrap or Tailwind modal will look broken. Also check CSP compatibility if the package injects inline scripts.
- Is it compatible with Livewire 3 wire:navigate page transitions?
- Only testing will tell, because wire:navigate introduces SPA-style transitions that the older lifecycle hooks did not account for. A loading hook that assumes full page loads can misfire or leave a spinner visible during navigation. Spike the package with navigate enabled and click through several pages, including a slow one. If it misbehaves, scoping the overlay to component updates only is usually the fix.
- How do I remove the package if I stop using it or want a custom spinner?
- Removal is cleanly additive in reverse: delete the Blade include from your layout, remove the published asset, then run composer remove bastinald/laravel-livewire-loader. There are no schema changes, no service providers altering the request path, and no data migrations to unwind. Because the package is just a thin wrapper over Livewire's client events, writing your own equivalent is a short afternoon of JavaScript work. That low switching cost is the strongest argument for adopting it in the first place.