Ban direct `useEffect` in React components. Use when writing, refactoring, or reviewing React code so derived state, data fetching, user actions, resets, and mount-only external synchronization use declarative replacement patterns instead of dependency-array choreography.
95
95%
Does it follow best practices?
Impact
98%
1.02xAverage score across 4 eval scenarios
Passed
No known issues
{
"context": "Tests whether react-ban-use-effect keeps user-caused work in handlers and replaces identity-change reset effects with component boundaries or equivalent declarative reset semantics.",
"type": "weighted_checklist",
"checklist": [
{
"name": "No direct useEffect",
"description": "The refactored code does not import `useEffect`, call `useEffect`, or call `React.useEffect`",
"max_score": 18
},
{
"name": "Submit in handler",
"description": "The save request is triggered directly from the click or submit handler, not via a state flag observed by an effect",
"max_score": 16
},
{
"name": "Flag state removed",
"description": "`shouldSubmit` or equivalent effect-trigger flag state is removed",
"max_score": 10
},
{
"name": "Reset semantics declarative",
"description": "Changing `user.id` resets draft state with a keyed child component, keyed boundary, or a clearly guarded render-time alternative rather than an effect",
"max_score": 16
},
{
"name": "Draft editing preserved",
"description": "The user can still edit the input locally before saving",
"max_score": 10
},
{
"name": "Scope controlled",
"description": "The solution does not rewrite unrelated form architecture or introduce a new form/data dependency without being asked",
"max_score": 8
},
{
"name": "Categories explained",
"description": "The report classifies the original effects as event-caused work and identity-change reset",
"max_score": 10
},
{
"name": "Verification named",
"description": "The report names lint/type/test checks and a small interaction check for editing, saving, and switching users",
"max_score": 12
}
]
}