state/snapshot

33 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

State behaves as a snapshot

React state behaves like a snapshot, not like a regular JavaScript variable. Setting state does not change the state variable in the already running code, but instead triggers a re-render. After calling setState, the state variable still holds the old value in the current function execution. This helps avoid subtle bugs.

State as snapshot example

When you set state, it does not immediately update the variable in the running code. For example: console.log(count); // 0, setCount(count + 1); // Request a re-render with 1, console.log(count); // Still 0! The state remains unchanged until the next render.

Force state reset using the key prop

By default, React preserves component state when re-rendering. To force a component to reset its state, pass it a different key prop (e.g., `<Chat key={email} />`). When the key changes, React treats it as a different component instance and re-creates it from scratch with the new data and UI state.

Props are immutable and read-only

Props are immutable, meaning they cannot be changed. A component cannot modify its own props. When a component needs different props in response to user interaction or new data, the parent component must pass different props. The old props will be discarded and eventually reclaimed by the JavaScript engine.

Props change over time and reflect component data at each render

Components may receive different props over time. Props are not always static—they can change between renders. Props reflect a component's data at any point in time, not just at the initial render. Every time a component is rendered, it receives a fresh copy of its props.

Tree position matters more than JSX structure

React determines state identity based on the position in the UI tree, not the structure of the JSX markup. If you have different JSX branches that render components at the same tree position, React treats them as the same component instance. This means multiple return clauses with different JSX can still preserve state if components appear in the same position.

Use key prop to reset component state at same position

By giving a component an explicit key, you tell React to treat it as a distinct instance. Changing the key causes React to destroy and recreate the component, resetting its state. Keys specify the position within the parent rather than relying on order alone. This is useful when you want to reset state while keeping the same component at the same tree position.

Keys are scoped to parent, not globally unique

Keys only need to be unique within their parent component. The same key value can be used in different parts of the tree under different parents.

Preserve state by lifting state to parent component

If you need to preserve state for components that get removed, you can lift the state up to the parent component instead of keeping it in the component itself. This way the data persists even when the component is not rendered.

State is tied to position in render tree

React keeps track of state by where a component sits in the render tree, not by where it is in the code. Each component instance at a specific position in the tree maintains its own isolated state. State is held by React and associated with the correct component based on its position in the tree.

React preserves state for same component at same position

React preserves a component's state for as long as it is rendered at the same position in the UI tree. If the component stays in the same position but receives different props, its state is preserved. The structure of the tree must match between renders for state to persist.

React destroys state when component is removed from tree

When React removes a component from the tree, it destroys its state immediately. If the same component is added back later, it starts with fresh state initialized from scratch.

Different component types at same position reset state

When a different component type gets rendered at the same tree position, React removes the old component and destroys its state before rendering the new component. This also resets the state of the entire subtree below that position.

Use index as key only for static lists

Using array index as a key can break state association when the list order changes. Only use index as key for static lists that are never filtered, reordered, or have items added/removed. For dynamic lists, use a stable identifier from the data.

Use localStorage to persist state across page reloads

To preserve state like form drafts when a user closes or reloads the page, save state to localStorage and initialize component state by reading from localStorage. This complements React state management for persistence.

Render components in different positions to reset state

If you conditionally render different instances of a component in mutually exclusive positions (one component in position A when condition is true, one component in position B when condition is false), React treats them as separate component instances and maintains separate state for each.

Use key with forms to clear input when switching context

When a component like a chat form needs to reset when switching to a different context (different recipient), assign a key based on that context. For example, use key={to.id} on a Chat component so the form clears when switching recipients.

Do not nest component function definitions

Never define a component function inside another component function. If you do, a different component function is created every render, causing React to see it as a different component type in the same position. This resets state on every render of the parent component and causes performance problems. Always declare component functions at the top level.

Reactive values definition

Props, state variables, and variables declared inside a component's body are called reactive values. They participate in the rendering data flow and can change due to a re-render. For example, in a component with a roomId prop and a message state variable, both roomId and message are reactive values, but a serverUrl constant is not.

State values in event handlers reflect previous render

When you set state inside an event handler and then immediately read that state variable in the same handler, you get the value from the previous render, not the newly set value. This is because state updates are queued and don't take effect until after the component re-renders.

Event handlers don't survive re-renders

Variables and event handlers don't survive re-renders. Every render creates its own event handlers. Event handlers created in one render have access to the state snapshot from that render, while event handlers created in a later render have access to the newer state snapshot.

setState timing and alert behavior

When you call setState and then immediately access state in an alert (synchronously in the same event handler), the alert will show the state value from the current render's snapshot, not the updated value. The updated state only appears in the next render. Example: setNumber(0 + 5); alert(number) will alert 0, not 5.

Snapshot pattern prevents timing bugs

The snapshot pattern where state is fixed within a render helps prevent timing bugs. Because state doesn't change within a render's event handlers, code that runs asynchronously (like a delayed alert or API call) will always reference the state values from when the user interacted with the component, not from whenever the async code eventually executes.

Re-rendering calls component function again with new snapshot

When React re-renders a component: 1) React calls your component function again, 2) Your function returns a new JSX snapshot, 3) React updates the screen to match the snapshot your function returned.

Setting state triggers re-render

Setting state does not change the state variable you already have, but instead triggers a re-render. When you call a setState function like setIsSent(true), React queues a new render with the updated state value.

Rendering takes a snapshot of state

When React renders a component, it calls your component function and you return a JSX snapshot. This snapshot includes props, event handlers, and local variables all calculated using the state at the time of that render. The UI snapshot is interactive and includes event handlers that specify what happens in response to inputs.

State lives in React outside the component function

State is not like a regular JavaScript variable that disappears after your function returns. State actually lives in React itself, outside of your function. When React calls your component, it gives you a snapshot of the state for that particular render.

State value is fixed within a single render

A state variable's value never changes within a single render, even if the event handler's code is asynchronous or calls setState multiple times. The value is fixed when React takes a snapshot of the UI by calling your component. Multiple setState calls in the same event handler all reference the same snapshot value from that render.

Multiple setState calls in one render only use current value

When you call setState multiple times in a single event handler with calculations based on state (like setNumber(number + 1) three times), each call uses the same state value from that render's snapshot. For example, if number is 0 and you call setNumber(0 + 1) three times, React will queue the state to become 1 (not 3), because all three calls set it to the same value: 0 + 1 = 1.

Event handlers see snapshot state even with async code

Event handlers created in a render will always see the state snapshot from that render, even if the code runs asynchronously later via setTimeout or other async operations. The state used in the event handler was fixed when the render occurred, and subsequent state changes do not affect code already scheduled to run from that event handler.

Immutability enables efficient child component re-render skipping

When data is immutable, React can cheaply compare whether data has changed by comparing object references. This allows components to skip re-rendering when their props haven't changed, improving performance.

Immutability enables undo/redo and performance optimizations

Immutability (not mutating data directly) is important in React for two reasons: it enables features like time travel/undo by preserving previous states, and it allows React to efficiently detect changes by comparing object references instead of deep comparisons.

State behaves like snapshot in event handlers

Inside event handlers, state behaves like a snapshot. After calling setState, the state variable will still reflect the value at the time the user triggered the event. To use the next value for calculations, define it manually.

Give your agent this brain