Async (HTTP)

Sooner or later the app talks to a server — and inherits errors, timeouts, retries, loading states, and stale replies racing each other.

re-frame2's answer is the managed request. Describe it as data, return it from a pure event handler, and finish. The runtime performs it. The reply arrives later as an ordinary event:

(:require [re-frame.core :as rf]
          [re-frame.http.managed])   ;; day8/re-frame2-http — forget this → :rf.error/no-such-fx

{:fx [[:rf.http/managed
       {:request    {:url "/api/articles/intro"}
        :on-success [:article/loaded]
        :on-failure [:article/load-error]}]]}

No await, no callback nesting, no resumed stack frame. Success and failure each have a name on the same wire as everything else.

Prerequisites. Effects — returning an effect map from a handler. Managed HTTP plugs into that pipeline; it does not replace events or app-db.

Scope

This section	Elsewhere
One request → one reply event (transport)	Resources — cache, stale, invalidate over this transport
Continuations as named events	Effects — dispatch-later, drain / run-to-completion
Custom promise/callback SDKs	Your own async effect

When not to use managed HTTP alone

Situation	Prefer
Same read on many screens, cache, invalidate	Resources
Multi-step lifecycle (login, websocket)	Machines
Non-HTTP async (Stripe, IndexedDB, worker)	Your own fx
No server yet	app-db + events

Reach for managed HTTP when one wire call needs a typed, testable reply — not when the load-bearing concept is a cache or a named stage machine.