* Refactor Gemini model display: filter old versions, group low/high pro, and improve naming * Fix potential negative minutes and refine Gemini 3 Pro grouping logic based on PR feedback * The account change process has been sped up * Address PR review: enhance error message and parameterize polling interval in process handler * Address PR review: fix potential race condition in database backup logic * fix: prevent renderer white screen and harden sentry gating * feat: localize model labels * chore: enable hoisted node-linker * chore: ignore .agent/.claude/.codex in prettier --------- Co-authored-by: Draculabo <[email protected]>
1.2 KiB
1.2 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Put Interaction Logic in Event Handlers | MEDIUM | avoids effect re-runs and duplicate side effects | rerender, useEffect, events, side-effects, dependencies |
Put Interaction Logic in Event Handlers
If a side effect is triggered by a specific user action (submit, click, drag), run it in that event handler. Do not model the action as state + effect; it makes effects re-run on unrelated changes and can duplicate the action.
Incorrect (event modeled as state + effect):
function Form() {
const [submitted, setSubmitted] = useState(false);
const theme = useContext(ThemeContext);
useEffect(() => {
if (submitted) {
post('/api/register');
showToast('Registered', theme);
}
}, [submitted, theme]);
return <button onClick={() => setSubmitted(true)}>Submit</button>;
}
Correct (do it in the handler):
function Form() {
const theme = useContext(ThemeContext);
function handleSubmit() {
post('/api/register');
showToast('Registered', theme);
}
return <button onClick={handleSubmit}>Submit</button>;
}
Reference: Should this code move to an event handler?