React (with Hooks, React 19 & Next.js basics)

In short: React is a JavaScript library (by Meta, 2013) for building user interfaces with reusable components.

• Features: declarative UI, component-based architecture, JSX, one-way data flow via props, state with hooks, efficient updates via reconciliation (virtual DOM diffing), a huge ecosystem, and React Native for mobile.
• It focuses on the view layer; routing, data fetching and SSR come from libraries or frameworks like Next.js.

In short: JSX is a syntax extension that looks like HTML inside JavaScript.

• A compiler (Babel, SWC, esbuild) turns it into function calls (jsx("div", props) / React.createElement) that create React elements.
• It supports embedding expressions in {}, uses className/camelCase attributes, and escapes values by default to prevent XSS.
• It's optional but universal.

In short: The virtual DOM is a lightweight in-memory tree of React elements describing the UI.

• On each render React creates a new tree, diffs it against the previous one (reconciliation) using heuristics — elements of a different type are replaced, same-type elements are updated, keys identify list items — and applies only the minimal changes to the real DOM in the commit phase.
• Fiber (React 16+) made this work interruptible and prioritised.

In short: Props are inputs passed from parent to child; they're read-only for the child.

• State is data owned and managed by a component (useState/useReducer) that changes over time and triggers re-renders when updated.
• A parent's state often becomes a child's props.
• Data flows down via props; children request changes via callback props.

In short: Keys give each list item a stable identity so React can match elements between renders and update, move or remove the right DOM nodes and preserve component state.

• Without good keys (or with array indexes when the list changes order), React may reuse the wrong component instance, causing bugs like inputs showing the wrong values and unnecessary re-renders.
• Use unique IDs from data; keys need to be unique only among siblings.

In short: useEffect(fn, deps) runs side effects (data fetching, subscriptions, timers, DOM APIs) after the component commits.

• With no deps it runs after every render; with [] once after mount; with [a, b] when those values change.
• Return a cleanup function from the effect to unsubscribe, clear timers or abort fetches — React runs it before re-running the effect and on unmount.
• Missing dependencies cause stale values; the ESLint hooks rule helps.

In short: Only call hooks at the top level of React function components or custom hooks — never inside loops, conditions, nested functions or after early returns — and only from React functions.

• React stores hook state in an ordered list per component and relies on the call order being identical on every render to match each useState/useEffect with its stored data.

In short: useMemo(() => compute(a, b), [a, b]) caches the result of an expensive calculation.

• useCallback(fn, deps) caches a function's identity so it doesn't change every render.
• React.memo(Component) skips re-rendering a component when its props are shallowly equal.
• They work together: memoised child + stable callback/object props.
• Use them where profiling shows a benefit; the React Compiler now automates most of this.

In short: Context passes data through the component tree without prop drilling: createContext, a provider with a value, and useContext in consumers.

• It suits low-frequency global values (theme, auth user, locale, feature flags).
• Avoid it for frequently changing, large global state, because every consumer re-renders on any change of the value — use a state library (Zustand, Redux Toolkit) or split contexts and memoise values.
• It's not a replacement for server-state caching.

In short: useState is ideal for simple, independent values.

• useReducer centralises complex state logic where the next state depends on the previous one and on multiple action types (forms with many fields, carts, wizards).
• Its reducer is pure and easily testable, and dispatch is stable, which helps memoisation.
• It often pairs with Context for small app-wide stores.

In short: When two components need the same changing data, move the state to their closest common parent and pass it down as props, with callbacks for updates.

• This keeps a single source of truth.
• If many layers are involved, consider composition (passing components as children), Context, or a store.

In short: Profile with React DevTools;

• avoid unnecessary re-renders (state colocation, splitting components, memo with stable props or the React Compiler, splitting contexts);
• virtualise long lists;
• correct keys;
• code-split routes and heavy components with lazy/Suspense;
• useTransition/useDeferredValue for heavy updates during typing;
• cache server data with TanStack Query;
• debounce inputs;
• use SSR/Server Components to reduce client JS;
• optimise images;
• always ship production builds.

In short: SSR renders the whole component tree to HTML on the server per request, then ships all the component JS to hydrate it in the browser.

• Server Components are components that run only on the server (or at build time): they can access databases and secrets directly, and their code is never sent to the browser — only their rendered output (RSC payload).
• Client Components ("use client") are still hydrated for interactivity.
• RSC and SSR are complementary — frameworks like Next.js use both.

In short: Find what re-renders with the Profiler.

• Usually the search state lives too high (in the page) so every widget re-renders.
• Move the search state down into the search component or the part that uses it;
• wrap expensive widgets in memo and pass stable props (or enable the React Compiler);
• use useDeferredValue for the filtered results so typing stays responsive;
• debounce the search before triggering data fetching;
• split a big context into smaller ones.

In short: Race condition: an older request resolves after a newer one and overwrites state.

• Fix by aborting the previous request in the effect cleanup (AbortController), or ignoring stale responses with a flag (`let ignore = false;
• return () => { ignore = true }`).
• Better: use TanStack Query/SWR or framework loaders, which key requests by parameters and handle caching, deduplication and races automatically.