You Might Not Need an Effect - discussion (2023-04-08)
This article tends to provoke strong reactions because it's really about boundaries: what should be derived in render vs synchronized in an effect. I like the argument when it's framed as "stop building invisible control loops" and start naming what changes (draft vs commit, lane transitions, identity boundaries).
What are the top 2-3 effects you successfully deleted, and what replaced them? Do you use a draft/commit split to avoid effects during typing, or do you synchronize continuously? How do you keep derived calculations from becoming expensive and hurting interaction performance?
Comments (12)
Back to latestWe deleted effects that only existed to keep two pieces of state in sync.
We replaced them with derivation + normalization.
Draft/commit split was the biggest effect killer for us. Once you stop treating every keystroke as committed state, you stop needing effects to "repair" state after the fact.
txt
[tips] input draft=q:"rea" reason=typing
[tips] input commit=q:"react" reason=enterKeyWe replaced a bunch of sync effects with a single normalized contract object.
Instead of setFoo, setBar, and then an effect to keep them consistent, we store { foo, bar, evidence } and derive the rest from it.
Concrete alternative: keep the effect, but make it a strict pattern (one effect, one boundary, one reason).
Deleting effects is great, but if you can't delete it, at least keep it narratable.
Yes. I think the article gets misread as "effects are evil".
The real win is deleting the ones that exist only to patch over duplicated state.
Docs tie-in: this fits the docs' focus on observable contracts and avoiding hidden orchestration.
Related: State Management and Performance and Rendering.
Long-form: the expensive derived-work problem is real, but effects aren't the only answer.
We keep derivation cheap by controlling identity: only recompute when a committed identity changes. Draft changes stay local and cheap; committed changes update the contract.
Once identity boundaries are explicit, the derived work stops exploding.
Short take: if you have an effect that only calls setState, you probably have duplicated state.
We deleted an effect that synced URL query params into local state.
The replacement was: parse/normalize query into route state, render from that, and let the URL be the single source of shareable truth.
Counterpoint: sometimes effects are the simplest place to integrate an external system.
But even then, don't let the integration effect also manage UI posture. Keep the contract separate.
The biggest mindset shift for our team was: if you can derive it, do it; if you can't, make the synchronization explicit and observable.
Once we adopted that, the number of "why did this run" bugs dropped a lot.
We added a tiny tips log that prints when we commit state, and it made debugging much easier.
It also discouraged people from committing on every keystroke.
Takeaway: deleting effects is a symptom of better boundaries.
If your boundaries are clear (identity + lane + evidence), you don't need effects to patch consistency.