Limits of automatic request cache invalidation in Mithril on route navigation

Answer

Mithril does not automatically invalidate its request cache when the route changes, so adding a built‑in hook would only be useful if you already manage a cache yourself.

Confirmed facts

• Mithril’s m.request performs no automatic caching; developers must implement their own caching mechanism.
• The router (m.route) supplies no lifecycle hook for request‑cache invalidation; you must clear caches manually in onbeforeleave or onremove.

Likely explanation

When a component is unmounted on navigation, any request data stored only in that component’s local state disappears, which may look like invalidation. Data kept in globals, closures, or singleton services survives the navigation, so the apparent “freshness” depends on where you store the cache.

Recommendation

1. If the cached data is scoped to a single route or component, clear it in the component’s onremove (or onbeforeleave) – this adds negligible overhead and guarantees freshness on navigation.
2. If the data is truly shared across routes, keep a global cache and invalidate it only when the underlying resource changes (e.g., via websockets or manual refresh); a route‑change hook would unnecessarily purge useful data.
3. Choose granularity based on data lifetime: per‑component for UI‑specific fetches, per‑route for route‑level resources, global only for truly shared data.

Missing diagnostic detail

Before deciding, confirm whether the cached data is intended to be shared across routes. If yes, avoid a global route‑change hook; if no, per‑component clearing is sufficient.