Laravel Dashboard Time Weather Tile Laravel Package

Getting Started

Prerequisites — check these before installing. This package is a leaf on top of spatie/laravel-dashboard. It ships nothing you can use standalone. Confirm three things first:

composer show spatie/laravel-dashboard   # must be v4.x
php -v                                   # must be 8.0+ (since 2.0.1)
grep -n "timezone\|locale" config/app.php

The tile major tracks the dashboard major (2.x ↔ v2, 3.x ↔ v3, 4.x ↔ v4). If the host dashboard is not already on v4, stop — you are really deciding to upgrade the dashboard, and the weather tile is a passenger, not a driver.

Install and register (an afternoon, including review):

composer require spatie/laravel-dashboard-time-weather-tile
php artisan vendor:publish --tag=time-weather-tile   # config + views

Then add the tile to config/dashboard.php's tiles array. The exact array shape (keyed vs. list, position vs. order) follows the dashboard major, so copy the pattern from an existing tile already on the page rather than from a tutorial:

'tiles' => [
    // ... existing tiles
    [
        'class' => \Spatie\TimeWeatherTile\TimeWeatherTileComponent::class,
        'position' => ['x' => 0, 'y' => 0, 'width' => 4, 'height' => 2],
    ],
],

Verify the class name in the source, it is faster than guessing:

grep -rn "class .*Tile" vendor/spatie/laravel-dashboard-time-weather-tile/src

Where to look first once it renders. Three files, in this order:

1. vendor/spatie/laravel-dashboard-time-weather-tile/src/ — the whole package is small enough to read end-to-end in one sitting. Do it. There is no tutorial corpus for this tile (11 stars, zero dependents), so the source is the documentation.
2. The published config — location, units, inside-temperature endpoint.
3. The Blade view — this is where styling drift will come from.

First use case. An internal ops wallboard or exec display pinned to one location, in one timezone, viewed by a handful of people. That is the sweet spot: low blast radius, obvious value, and the weather provider's coverage question gets answered by the people actually standing in front of it.

Time-boxed spike (hours, not days). Success criteria, nothing more: correct local time, plausible current weather. If either fails, record why and close the ticket — a negative result here costs an afternoon instead of a quarter.

Implementation Patterns

Validate geography before anything else. The changelog history points at Buienradar, a Netherlands-centric provider with no API key and no SLA. This is the pivot point of the whole integration. Render the tile from each region your users sit in, with a real location, and look at it:

// tinker — sanity-check what the tile would display
app(\Spatie\TimeWeatherTile\TimeWeatherTileComponent::class);

If weather is blank or wrong outside NL, the honest framing for stakeholders is "we adopted a dashboard framework and got a clock." Decide the fallback (clock-only vs. remove) now, not after rollout.

Two locations = a subclass, not a config entry. The tile config is application-wide. For a second site you want a separate class with its own parameters, registered as its own tile:

namespace App\Tiles;

use Spatie\TimeWeatherTile\TimeWeatherTileComponent;

class AntwerpTimeWeatherTile extends TimeWeatherTileComponent
{
    // Override whatever the parent reads from config
    // (location / country / units / inside-temp endpoint) with
    // hardcoded or constructor-injected values.
}

Only do this if there is a named consumer for the second location. Otherwise you have doubled your styling and upgrade surface for decoration.

Own the weather fetch if you care about the TTL. The default behavior is a cached outbound HTTP call. If the deployment is multi-node, confirm the cache store is shared — a per-node file cache silently multiplies requests by node count, which is cheap to fix and annoying to discover during an incident. If you need tighter control, move the fetch into your own wrapper and let the tile read the cached result:

Cache::remember('weather.current', now()->addMinutes(10), function () {
    return retry(2, fn () => Http::timeout(5)->get($url)->json(), 200);
});

Cache TTL should be ≥ the dashboard refresh interval and ≥ the provider's fair-use tolerance under concurrent viewers.

Set the failure posture in the same PR as the install. Since 1.3.1 the tile degrades instead of crashing when the provider is unavailable — the right instinct, but on a wallboard a silently stale tile is visually identical to a broken dashboard. Pick one and implement it immediately:

• Silent degradation — accept it, do nothing, but write down that you accepted it.
• Visible staleness — render the timestamp of the last successful fetch inside a subclassed view.
• Hide the tile — catch the exception and return an empty render.

The point is that this is a product decision made before the first outage, not an engineering improvisation during it.

Inside temperature. Since 1.3.0 the tile can display an inside temperature from an endpoint you supply; since 2.0.2 the span hides cleanly when unset. If you have no real sensor behind it, leave it unset — do not wire it to a stub that renders an empty label on a wallboard.

Styling: publish only with an owner. Publishing the Blade views is a one-line decision with an indefinite maintenance tail. Publish if (a) you need to match a non-Tailwind design system or (b) someone is named as owner of those views. Otherwise take the defaults and accept minor drift — an unowned published view is future breakage with no author.

Keep the upgrade unit atomic. Pin the tile and the dashboard together, and test them together:

composer require spatie/laravel-dashboard:^4 spatie/laravel-dashboard-time-weather-tile:^4 -W

Then render the page. A host dashboard major bump with a mismatched tile major is a blank tile or a boot failure, and it will not announce itself.

Testing. Fake the outbound call and assert the tile renders — you are testing your wiring, not the weather:

Http::fake(['*' => Http::response($this->fixture(), 200)]);

Livewire::test(TimeWeatherTileComponent::class)
    ->assertSee('Amsterdam')
    ->assertStatus(200);

Commit a fixture of a real provider payload. It is the only cheap regression test you will ever get against a format change you do not control.

Gotchas and Tips

The clock freezes if the dashboard refresh interval is too slow. The time is rendered as part of the Livewire component. The dashboard's refresh_interval_in_seconds governs how often it re-renders. A 15-minute interval means a wallboard showing a confidently wrong time for 15 minutes out of every 15. Set it to something a clock can live with.

Timezone is the highest-embarrassment failure and the cheapest to close. As of 4.1.0 the clock uses the configured timezone rather than the server default. Verify config/app.php → timezone is correct, and check nobody is calling date_default_timezone_set() in a service provider. Per-user timezone overrides are out of scope — if your users span zones, one of them gets a wrong clock, and that needs a decision rather than a workaround.

Locale drives the date format (since 1.0.1). A wallboard in an English office with APP_LOCALE=nl will render Dutch month names. Not a bug — a config mismatch that reads like one.

Units are configurable (since 1.1.0) and default to the author's locale assumptions. Check them against your audience on day one; someone will notice a Celsius reading on a Fahrenheit wallboard within an hour.

Degradation is silent. Repeating it because it is the single most likely operational surprise: no crash, no error page, just weather that stopped updating. If nobody is watching the tile, nobody will notice the provider changed its payload shape. Commit a fixture test, or accept that you find out from a passerby.

No community to escalate to. Zero dependents means zero peer implementations, no Stack Overflow answers, no blog posts. The escalation path is: read the source (minutes — it is tiny), open a GitHub issue, or fork under MIT. The fork option is real, not a polite fiction — an internal patch here is an afternoon. Tell stakeholders that is the safety net rather than overstating upstream guarantees.

Spatie's brand mitigates abandonment, not knowledge risk. The package is actively released (most recently 2026-04-28), so silence does not mean stability is coming — track releases rather than assuming stillness.

Feature ceiling, surfaced early. No forecast, no history, no alerts, no interactivity. "Can we show a weather trend?" is a different project, not a config change. Say so in the first conversation rather than the third.

Debugging checklist when the tile looks wrong:

1. Is it weather or time? (Time → timezone/locale/refresh interval. Weather → network/provider/coverage.)
2. Http::fake() a recorded payload and re-render — isolates your code from theirs.
3. Dump the raw response from the fetch class; a shape change shows up immediately.
4. Check storage/logs for swallowed exceptions — since 1.3.1, failures can be caught quietly.
5. Drop the cache (php artisan cache:clear) before concluding the fetch is broken.

Write down keep / remove / extend after a 2–4 week pilot. A tile this small becomes load-bearing through inattention, not through decision. The written record is what stops a forgotten config entry from being someone's surprise during the next dashboard upgrade.