reagent-migration

Run the reagent-to-fresco codemod reporter first to census Reagent API call sites and fix the [:> …] prop dialect, then convert views one closed subtree at a time, leaf to root. Each rewrite cites a MIG-NN rule id, and the project's compile and test gates run after every pass.

No. re-frame2 ships a first-class, actively supported Reagent adapter, so a v1 app swaps the dependency, installs the adapter, and keeps its view code. Rewriting views into Fresco is a separate, optional second step for authors who specifically want Fresco.

Three cases stay on Reagent: the component-did-update prev-props protocol, a frame-pinned reactive read, and Reagent's own component introspection and schedulers. The skill holds those views on Reagent and states the reason rather than forcing a conversion.

A leftover #(dispatch …) closure compiles and renders because Fresco passes plain functions to React by identity, but at click time there is no render extent, so ambient dispatch raises :rf.error/no-frame-context. Convert each view whole and grep converted bodies for surviving closures.

Fresco has no view-local state tier by design. Each r/atom becomes an ownership decision: product state moves to app-db via h/reg-state, draft-and-commit controls use re-frame.fresco.forms/buffered-field, and genuine widget mechanics go to a React island with real hooks.

Yes. A one-off crossing keeps the [:> Component …] escape, and a repeated crossing is declared once with h/defhost. Callback contracts are inferred from prop spelling, with a :callbacks override for vendors whose on*-named prop is actually a render prop.