A trail-alert board must say whether there are alerts or a request failed. The preview is intentionally powered by an explicit in-page mock fetch, so it works offline and never claims to show live data.
The previous library demo separated three outcomes: a nonempty array, an empty array, and a failed request. Here the selectable alert fixture also supports HTTP 503 and a rejected Promise. The values are deterministic local examples, not the current conditions on any trail.
An unrelated shipping-status viewer could start like this:
async function checkShipment() {
message.textContent = "Checking…";
try {
const response = await mockFetch("/api/shipment");
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const events = await response.json();
message.textContent = events.length ? "Events found." : "No events yet.";
} catch (error) {
message.textContent = `Unable to check: ${error.message}`;
}
}
For the alert board, choose a scenario and click Check alerts. Read the status before and after the asynchronous result. Build alert items with textContent; use the status to distinguish “no alerts” from “could not check.” response.ok is required even though the mock returns a Response, because a Response with 503 is still delivered successfully to JavaScript.
Checking alerts… and start mockFetch for the selected mode.li elements.No alerts right now..response.ok before JSON; on an HTTP failure clear old alerts and say Could not load alerts..