{"dataset":{"id":"00000000-0000-0000-0000-000000000009","slug":"react-best-practices","name":"React best practices","description":"Source-linked guidance on React fundamentals: rules of Hooks, avoiding unnecessary Effects, state structure, key-based state reset, and pure rendering. Scoped to React itself; not a framework-specific corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Keeping Components Pure","sourceUrl":"https://react.dev/learn/keeping-components-pure","text":"React assumes every component you write is a pure function, which means two things: it minds its own business, not changing any objects or variables that existed before it was called, and it returns the same JSX for the same inputs. Purity makes components safe to run in a different environment such as the server, safe to skip re-rendering when inputs have not changed, and safe to abandon mid-render when newer data arrives. Rendering can happen at any time, so components must not depend on each other's rendering sequence, and you must not mutate the inputs used for rendering — props, state, or context — but instead set state to update the screen. Local mutation is the exception: changing variables created during the same render is fine because no outside code can observe it. Side effects such as updating the screen, starting an animation, or changing data belong in event handlers, which do not run during rendering and therefore do not need to be pure; calling useEffect for a side effect should be a last resort after other options are exhausted. Strict Mode calls each component's function twice during development to surface impurity, and has no effect in production. Scope: React rendering. Reviewed October 4, 2026.","id":"react-best-practices:Keeping Components Pure","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Preserving and Resetting State","sourceUrl":"https://react.dev/learn/preserving-and-resetting-state","text":"State is isolated between components and is tied to a position in the render tree: React associates each piece of state with a component by where that component sits in the tree, not by the JSX tag that produced it. React preserves a component's state for as long as the same component type is rendered at the same position; if it is removed, or a different component type takes its position, React discards the state of the whole subtree. This is why nesting component definitions is a bug — a new function is created on every render, so React sees a different component at the same position and resets all state below; always declare component functions at the top level. To reset state deliberately, either render components in different positions or give each one an explicit identity with a key: specifying a key tells React to use the key itself as part of the position instead of order within the parent, so two counters with keys Taylor and Sarah never share state. Keys are not globally unique; they only specify position within the parent, and resetting a form with a key is a particularly useful application. Scope: React rendering and reconciliation. Reviewed October 4, 2026.","id":"react-best-practices:Preserving and Resetting State","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Choosing the State Structure","sourceUrl":"https://react.dev/learn/choosing-the-state-structure","text":"Five principles guide state structure, all aimed at making state easy to update without introducing mistakes. Group related state: if two or more state variables always update at the same time, consider merging them into one — remembering that updating a single field of a state object requires explicitly copying the other fields, for example setPosition({ ...position, x: 100 }). Avoid contradictions: when several pieces of state can disagree with each other, such as isSending and isSent both being true, you leave room for mistakes. Avoid redundant state: if you can calculate information from props or existing state during rendering, such as fullName from firstName and lastName, do not put it in state. Avoid duplication: when the same data lives in multiple state variables or nested objects, keep only an ID in state — for example selectedId instead of a duplicated selectedItem object — and look the item up during rendering. Avoid deeply nested state: deeply hierarchical state is inconvenient to update because every change requires copying objects all the way up the chain, so prefer a flat structure. Scope: React function components. Reviewed October 4, 2026.","id":"react-best-practices:Choosing the State Structure","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"You Might Not Need an Effect","sourceUrl":"https://react.dev/learn/you-might-not-need-an-effect","text":"Effects are an escape hatch from the React paradigm for synchronizing a component with an external system such as a non-React widget, the network, or the browser DOM; when no external system is involved, an Effect usually is not needed. You do not need Effects to transform data for rendering: an Effect that updates state when inputs change causes an entire render pass with a stale value followed by an immediate re-render, so transform the data at the top level of the component instead, where it re-runs automatically whenever props or state change. You do not need Effects to handle user events either; put that logic in the corresponding event handlers. To cache an expensive calculation, add useMemo rather than useEffect. To reset the state of an entire component tree when a prop changes, pass a different key; to reset only part of the state, adjust it during rendering — React throws away the returned JSX and immediately retries, and only the same component's state may be updated this way, guarded by a condition to avoid loops. When fetching data, prefer a framework's built-in mechanism or a custom Hook over raw Effects, and implement cleanup to avoid race conditions. Scope: React function components. Reviewed October 4, 2026.","id":"react-best-practices:You Might Not Need an Effect","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Rules of Hooks","sourceUrl":"https://react.dev/reference/rules/rules-of-hooks","text":"Functions whose names start with use are Hooks, and two rules govern where they may be called. First, only call Hooks at the top level of a React function, before any early returns: never inside loops, conditions, nested functions, event handlers, class components, try/catch/finally blocks, or functions passed to useMemo, useReducer, or useEffect. Second, only call Hooks from React functions — function components and custom Hooks — never from regular JavaScript functions. Custom Hooks may call other Hooks because they themselves are supposed to run only while a function component is rendering. Following these rules keeps all stateful logic in a component clearly visible from its source code. The eslint-plugin-react-hooks plugin catches violations automatically; making that lint rule a hard build error rather than a warning is Koskamo editorial guidance. Scope: React function components and Hooks. Reviewed October 4, 2026.","id":"react-best-practices:Rules of Hooks","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}