Loading Laravel Package

Getting Started

• composer require sarfraznawaz2005/loading
• Laravel auto-discovery registers Sarfraznawaz2005\Loading\LoadingServiceProvider; no manual provider registration needed on Laravel 9/10.
• Publish config/assets: php artisan vendor:publish --tag=loading (verify the tag in the service provider if it differs), then review config/loading.php for enable/disable, spinner style, and overlay behaviour.
• Add the Blade directive immediately before </body> in your main layout (e.g. @loading), which injects the overlay markup and the JS that shows it on navigation/submit.
• First use case: a classic server-rendered Blade app where you want a spinner/overlay on every form post and full page navigation without writing any JS.

Where to look first: config/loading.php, then the service provider (to see which directive/Blade component is registered), then the published views/assets if you need to restyle.

Implementation Patterns

• Put the directive in layouts/app.blade.php once so it covers every page using that layout, rather than per-view — this is the intended day-to-day usage.
• Full-page form posts are the sweet spot: the overlay appears on submit and disappears on unload. Leave it on for checkout, login, and create/update forms.
• Opt out where the overlay hurts: search-as-you-type, filter dropdowns, logout, and any form you submit via JS. Add the package's skip attribute (confirm the exact name in the published JS/config) rather than removing the directive for the whole page.
• AJAX/fetch/axios: the overlay is tied to native submit/navigation events, so it won't cover XHR-driven flows. Toggle the overlay manually around the promise, or scope the directive to only the pages that do full reloads.
• Livewire/Inertia: the package is unaware of both. Use wire:loading for Livewire and Inertia router events for Inertia, and keep @loading off those pages — otherwise you get a stuck overlay after an intercepted submit.
• Multiple layouts (public, admin, auth): add the directive to each; wrap it in a small partial if you want to gate it behind a config flag or feature toggle.
• Styling: override the published CSS/views in your own assets rather than editing files under public/vendor/, so npm run build and redeploys don't clobber your changes.
• Browser tests: the overlay can intercept clicks in Dusk. Wait for it to disappear before asserting or clicking (->waitUntilMissing('.loading-overlay'), class per your published markup).

Gotchas and Tips

• 1.4.0 only adds explicit Laravel 9/10 support. There is no declared Laravel 11/12 support, so check composer.json constraints before upgrading the framework — you may need to pin or fork.
• The directive must be inside <body>. Placed in <head>, the overlay element won't exist when the JS initialises and nothing appears to work.
• After publishing config or views, run php artisan view:clear and php artisan config:clear. Stale compiled views are the most common cause of "I changed it and nothing happened".
• Stuck overlay is almost always a form that submits via JS (never triggering a real navigation) or a client-side validation failure. Explicitly hide the overlay on DOMContentLoaded/pageshow events as a safety net, including bfcache restores.
• The overlay is a visual guard, not a lock. Still make POST handlers idempotent (or disable the submit button) for payments and orders — double submits still get through.
• Assets: published files land in public/vendor/loading and need a real deploy step. Pipelines that ignore public/ during build will ship a page with an invisible-but-blocking overlay.
• Accessibility: the default spinner isn't announced to screen readers. Publish the views and add role="status" plus aria-live="polite" (and a text label) to the overlay element.
• To keep local/testing runs clean, gate the directive behind config('loading.enabled') (or your own env check) so the overlay doesn't interfere with automated browser tests.