MDN Fetch API - discussion (2023-02-06)
Every time a team argues about data fetching patterns, half the disagreement is actually about the underlying primitive. MDN's Fetch docs are worth re-reading because they clarify what fetch does and doesn't do, which makes it easier to build an honest lane/evidence story on top.
Do you treat abort as a normal lane, or do you fold it into errors? How do you encode freshness decisions (cache vs bypass) so the UI remains explainable? What do you log as the minimal fetch contract so debugging isn't guesswork?
Comments (14)
Back to latestAbort is a normal lane. If you treat it as an error, your monitoring becomes a lie.
Most aborts are user intent (navigate away, change filters). That shouldn't look like failure.
We made fetch a contract with explicit lanes and reasons, and we log only transitions:
txt
[tips] fetch lane=pending reason=route:enter key=forecast:sf cacheLane=bypass
[tips] fetch lane=aborted reason=nav:back key=forecast:sf
[tips] fetch lane=ok reason=fetch:resolve key=forecast:sf freshnessAt=2023-02-12T12:12ZThe log isn't telemetry. It's evidence for a human who has to debug.
Counterpoint: it's easy to build a lane taxonomy that's more complex than the app.
We keep it small: pending | ok | error | aborted, and we don't add new lanes unless the UI needs a different behavior.
Totally. Lanes exist to explain behavior, not to win architecture points.
If two lanes render the same, they probably should be one lane.
Freshness decisions have to be visible. If the UI doesn't tell you whether it's bypassing cache, people will argue about whether it's stale.
We render data-cache-lane (and a timestamp) in debug mode so screenshots settle debates.
Long-form argument: fetch is not the problem; *invisible fetch behavior* is the problem.
Teams build folklore because nobody can see what request happened, which posture was chosen, or why it changed.
If you log reason + key + posture and render a minimal evidence line, fetch bugs become normal bugs.
One practical thing from MDN: remembering that fetch only rejects on network errors changes how you model error lanes.
We treat non-2xx as error with a structured payload, not as a thrown exception path.
Counterpoint: rendering too much network evidence can be user-hostile.
We keep the evidence behind a debug flag and show only a tiny user-level affordance (retry, last updated) in normal mode.
We had fewer flakes in tests after we stopped waiting on timers and started waiting on lanes.
If data-fetch-lane=ok, the test knows the work is done without guessing how long it takes.
Long-form counterpoint: logs can become a crutch if they replace good UI contracts.
If the UI doesn't expose enough truth (timestamps, lane indicators, selected identity), you'll end up reading logs for basic behavior.
Logs should explain, not compensate.
Docs tie-in: the data fetching posture docs here are basically "how to build a predictable story on top of fetch".
Related: Data Fetching and Caching (Best Practices) and Testing and Debugging.
We also log "merge winners" when two panels fetch the same key and disagree.
Silent merging is where bugs go to live.
Abort handling was easier when we treated abort as a success-ish outcome.
We don't show an error toast for abort; we show nothing, but we keep the lane in debug evidence for triage.
If you want a minimal contract: key, lane, reason, and freshnessAt.
Everything else is optional. But without those four, you're debugging blind.
MDN is still the best place to learn what fetch actually does. Once you accept the primitive, you can build a coherent posture on top.
The primitive doesn't have to be magical for the app to feel predictable.