Component Lifecycle
The stages a piece of UI passes through: it appears (mount), it updates when data changes, and it gets removed (unmount).
See it
What it is
Three moments. Mount: the component lands in the DOM for the first time, so this is where you open a connection, focus a field, or kick off a fetch. Update: props or state changed and it re-rendered. Unmount: it's removed, so cancel timers, unsubscribe, abort requests. Old React class components named all three out loud (componentDidMount, componentDidUpdate, componentWillUnmount) and Vue still does (onMounted, onUpdated, onUnmounted). Modern React reframes all of it as synchronization rather than three named moments. An effect's body is setup that runs after commit, its returned function is cleanup that runs before the effect reruns and again at unmount, and the dependency array decides how often that pair repeats. The 'before it reruns' half is the part the class model had no slot for. One effect per external thing you are syncing with, too, not one effect that does everything the component happens to need.
You reach for the lifecycle when behavior is tied to being on screen: playing a video, holding a websocket open, registering a keyboard shortcut, measuring an element once layout exists, pausing polling when the panel closes.
Gotcha: mounting is not 'runs once, forever'. Change a component's key or move it to a different position in the tree and the framework unmounts and remounts it, wiping its state. The reverse bites harder: reuse the same position with different data and the old state sticks around, which is why a modal flashes the previous item for a frame. Keys control identity, and identity controls the lifecycle.
Ask AI for it
Refactor this component's lifecycle behavior into one effect per external resource it touches, rather than a single effect doing everything. For each one: set up in the effect body so it runs after commit, return the cleanup that releases exactly what that setup acquired, and list the exact reactive values it reads so the cleanup runs before the dependencies change and again on unmount. Keep unrelated concerns apart, so a socket, a timer, and a keyboard listener are three effects, not one. Add a key to remount the component only if switching to a different entity is meant to discard all of its local state, and say explicitly whether that is the intent. Finish with a short list: each effect, the resource it owns, and what its cleanup releases.