Summary
The 3.0 release notes and migration guide state that the Reagent functional compiler is enabled by default and needs no consumer action. It is only enabled in wire's spec helper, so consumers get function components in their tests and class components in production unless they opt in themselves.
What the docs say
CHANGES.md, 3.0.0:
- All components now render as React functional components (functional compiler enabled by default)
docs/migrating-to-3.0.0.md, under What Wire Handles Automatically — "no changes needed in your code":
- Functional compiler —
with-let finally blocks fire properly on unmount
What the code does
In wire 4.2.1, set-default-compiler! appears exactly once across every .clj / .cljs / .cljc file in the repo:
;; src/cljs-react/c3kit/wire/spec_helper.cljs:35
(reagent/set-default-compiler! (reagent/create-compiler {:function-components true}))spec_helper is a test namespace. Production builds never load it, so the default compiler stays class-based in the deployed app.
Impact
Specs and production render different component types, which is exactly the divergence that makes a test suite stop being evidence. Concretely, it means:
with-let finally cleanup semantics differ between tests and production.- Hook-based behavior verified under test is not what ships.
:f> markers look redundant when you check against the suite (the suite is already functional), but removing them actually changes production behavior.
We hit this on three separate ClojureScript apps migrating 2.8.x -> 4.2.1. In each one the suite was fully green and gave no indication that production was still on the class compiler.
Suggested fix
Any of:
-
Set the default compiler from a namespace that production loads — e.g. when any React-flavored c3kit.wire.* namespace is required, alongside the existing c3kit.wire.flash auto-registration described in the 4.0.0 notes.
-
Leave it to consumers but correct the docs: state that wire sets it for tests only, and that applications must call it themselves in their entry namespace:
(reagent/set-default-compiler! (reagent/create-compiler {:function-components true}))
-
Add it to docs/migrating-to-3.0.0.md as an explicit migration step rather than listing it under "handled automatically".
Option 1 matches what the changelog already promises. Option 2 is the smallest change and removes the trap.
Happy to send a docs PR for option 2/3 if that is the direction you prefer.
Summary
The 3.0 release notes and migration guide state that the Reagent functional compiler is enabled by default and needs no consumer action. It is only enabled in wire's spec helper, so consumers get function components in their tests and class components in production unless they opt in themselves.
What the docs say
CHANGES.md, 3.0.0:docs/migrating-to-3.0.0.md, under What Wire Handles Automatically — "no changes needed in your code":What the code does
In wire 4.2.1,
set-default-compiler!appears exactly once across every.clj/.cljs/.cljcfile in the repo:spec_helperis a test namespace. Production builds never load it, so the default compiler stays class-based in the deployed app.Impact
Specs and production render different component types, which is exactly the divergence that makes a test suite stop being evidence. Concretely, it means:
with-let finallycleanup semantics differ between tests and production.:f>markers look redundant when you check against the suite (the suite is already functional), but removing them actually changes production behavior.We hit this on three separate ClojureScript apps migrating 2.8.x -> 4.2.1. In each one the suite was fully green and gave no indication that production was still on the class compiler.
Suggested fix
Any of:
Set the default compiler from a namespace that production loads — e.g. when any React-flavored
c3kit.wire.*namespace is required, alongside the existingc3kit.wire.flashauto-registration described in the 4.0.0 notes.Leave it to consumers but correct the docs: state that wire sets it for tests only, and that applications must call it themselves in their entry namespace:
Add it to
docs/migrating-to-3.0.0.mdas an explicit migration step rather than listing it under "handled automatically".Option 1 matches what the changelog already promises. Option 2 is the smallest change and removes the trap.
Happy to send a docs PR for option 2/3 if that is the direction you prefer.