What this prompt does
This prompt makes the model a senior Laravel engineer and asks it to build a working Livewire 3 real-time dashboard, returning real component code and Blade rather than pseudocode. It defines six deliverables: a Livewire 3 component class with typed public properties and computed properties for the metrics, live updates via your chosen transport (wire:poll at an interval or Reverb broadcasting with listeners), loading and skeleton states using wire:loading so the dashboard never flashes empty, optimistic UI for user actions with rollback on failure, error recovery with retry on transient failures and a visible reconnecting indicator, and eager-loaded queries to avoid N+1 on every refresh. All data is scoped to the current user/team. The structure works because it confronts the real trap: re-running heavy queries on every poll until the database melts.
Three variables drive it. [use_case] describes what the dashboard shows, like a live orders dashboard, which shapes the metrics and component. [transport] chooses the realtime mechanism, such as Laravel Reverb websockets, which decides whether you get wire:poll or broadcasting wiring. [interval] sets the poll/refresh cadence, like 5s, used when polling. The eager-loading and caching guidance is load-bearing: pick Reverb over polling once you pass a few hundred concurrent users, and cache the aggregate queries so the DB doesn't melt under refresh pressure.
When to use it
- You are building a real-time dashboard in Laravel with Livewire 3 for a client SaaS.
- You need to choose between wire:poll and Reverb websockets and wire it correctly.
- Heavy aggregate queries risk re-running on every poll and overloading the database.
- You want loading and skeleton states so the dashboard never flashes empty.
- Optimistic UI with rollback on failure is part of the experience.
- Error recovery with retry and a visible reconnecting indicator matters.
Example output
Expect the component class, its Blade view, and any event/listener wiring in separate code blocks. The Livewire 3 component has typed public properties and computed properties for the [use_case] metrics, scoped to the current user/team; live updates use [transport] — wire:poll at [interval] or Reverb broadcasting with listeners; wire:loading drives loading and skeleton states; user actions get optimistic UI with rollback on failure; error recovery retries transient failures and shows a reconnecting indicator; and queries are eager-loaded to avoid N+1 on every refresh. It is buildable Livewire code you adapt to your app.
Pro tips
- Set
[use_case]specifically so the computed properties target the right metrics rather than generic placeholders. - Pick Reverb over polling once you pass a few hundred concurrent users to spare the database.
- Tune
[interval]carefully when polling; too tight a cadence multiplies query load across all viewers. - Cache the aggregate queries so heavy metrics don't re-run from scratch on every refresh.
- Keep all data scoped to the current user/team, since the prompt requires tenancy-safe queries.
- Rely on wire:loading skeleton states so the dashboard never flashes empty between refreshes.
