React 16 · Summary🔓 free after sign-in

Summary: the principles of React

The 15 principles of the whole course, explained with "not like this / like this" examples.

Before we start: from analogies to principles

Throughout the course you've been accompanied by images from ordinary life: a cook with no memory, a notebook, a bank account, a school PA system, a hotel with a front desk. They had a single purpose – to make you recall, for every topic, why it works the way it does. When you write your own app, you won't have a lesson at hand, but you will remember these images.

This lesson brings nothing new. It takes everything you've seen in the course and puts it together into fifteen principles from which you can derive almost any decision when writing React. For each principle you'll find an analogy, an explanation of why it holds, a "not like this / like this" example and a link to the lesson where the topic is covered in detail.

UI is a function of state
A component is a recipe, props are the order.
Minimal state, one source of truth
A cook doesn’t write down “number of guests” – they count it from the list.
State is a snapshot, change it by replacing
A render is a film frame; React only notices a change when you hand it a new sheet of paper.
Every kind of state has its place
Moving house: fridge, envelope, desk, pocket, shared pantry.
Events in handlers, synchronisation in effects
An effect is the light in a room: switch on, switch off, switch over.
Refs are an emergency exit
State is the menu board, a ref is the drawer under the counter.
Describe what happened, not how to change it
A bank account: transactions instead of overwriting the balance.
Context delivers, it doesn’t manage
The school PA system: the Provider broadcasts, whoever wants to listens.
Custom hooks share logic, not state
A white sauce recipe: one procedure, every dish gets its own pot.
Forms: let the platform do the work
A clerk looking over your shoulder, or a form handed in at the front desk.
Performance: structure first, memo later
A kitchen at rush hour: measure, reorganise, only then special tricks.
Composition over configuration
Lego instead of a ready-made toy.
Types where nonsense can’t be written
Labels on boxes; a postal form with “letter or parcel”.
The URL is state too
A hotel: the address is the room number, search params are requests for the room.
Server data is a cache
A copied-out price list and the person who looks after the notice board.

1. UI is a function of state

All of React rests on one equation: UI = f(state). A component is a function that computes from props and state what the screen should look like. It doesn't draw or modify anything itself – it returns a description (JSX) and React makes sure the DOM matches it.

Three rules follow from this:

Rendering must be pure. Same inputs → same output, no side effects (no API calls, no writing to variables outside the component, no mutating props). React may run a render whenever and as often as it likes – in Strict Mode it deliberately runs it twice to expose impurity.
Props are read-only. When you need to change data, whoever owns it changes it (via state and a callback).
Don't think in steps, think in states. Don't ask "what do I hide and what do I show after the click", ask "what should the UI look like in each state".

// ❌ Impure render: it changes data outside itself and the result depends on how many times it was called
let renderCount = 0
function Guest({ name }: { name: string }) {
  renderCount++
  return <li>#{renderCount} {name}</li>
}

// ✅ Pure render: everything it needs comes from outside
function Guest({ name, order }: { name: string; order: number }) {
  return <li>#{order} {name}</li>
}

// ❌ Imperatively: "after the click hide the button, show a spinner, then show the message…"
// ✅ Declaratively: describe each state separately, React handles the transitions
function Submit({ status }: { status: 'idle' | 'sending' | 'sent' }) {
  if (status === 'sending') return <Spinner />
  if (status === 'sent') return <p>Sent ✔</p>
  return <button type="submit">Send</button>
}

📚 In depth in the lesson A quick refresher of the basics.

2. Minimal state, one source of truth

Only what changes over time and can't be computed from anything else belongs in state. Everything else is a prop, a constant, or a value computed during render. Every piece of information should have exactly one place where it lives – as soon as you have it twice, sooner or later the copies drift apart.

// ❌ Duplicated state + an effect that "catches up"
const [todos, setTodos] = useState<Todo[]>([])
const [filter, setFilter] = useState<'all' | 'done'>('all')
const [visible, setVisible] = useState<Todo[]>([])
const [doneCount, setDoneCount] = useState(0)

useEffect(() => {
  setVisible(filter === 'all' ? todos : todos.filter((t) => t.done))
  setDoneCount(todos.filter((t) => t.done).length)
}, [todos, filter])
// → an extra render, stale values for a moment, more places for bugs

// ✅ Only the necessary state, compute the rest
const [todos, setTodos] = useState<Todo[]>([])
const [filter, setFilter] = useState<'all' | 'done'>('all')

const visible = filter === 'all' ? todos : todos.filter((t) => t.done)
const doneCount = todos.filter((t) => t.done).length

The same principle applies to selection: don't store a copy of the selected object, store its ID.

// ❌ A copy: after the item is renamed, the detail still shows the old name
const [selected, setSelected] = useState<Item | null>(null)

// ✅ ID + lookup during render: always up-to-date data
const [selectedId, setSelectedId] = useState<string | null>(null)
const selected = items.find((i) => i.id === selectedId) ?? null

Question	If yes…
Does it come from the parent?	It’s a prop, not state.
Does it never change?	It’s a constant (feel free to put it outside the component).
Can it be computed from other state/props?	Compute it during render (useMemo if it’s expensive).
Is it a copy of something already in state?	Store just the ID or key.
Does it change and must the UI react to it?	Only now is it state.

📚 In depth in the lesson State and events.

3. State is a snapshot, change it by replacing

A state value is frozen within a single render. setCount(count + 1) doesn't change count right away – it schedules a new render in which count will be new. All handlers and effects from a given render keep seeing its snapshot.

function Counter() {
  const [count, setCount] = useState(0)

  const addThree = () => {
    // ❌ All three lines read the same snapshot (0) → the result is 1
    setCount(count + 1)
    setCount(count + 1)
    setCount(count + 1)
  }

  const addThreeOk = () => {
    // ✅ An updater always receives the latest value → the result is 3
    setCount((c) => c + 1)
    setCount((c) => c + 1)
    setCount((c) => c + 1)
  }
}

React detects a change by comparing references (Object.is). If you mutate an object or array, the reference stays the same and React redraws nothing. That's why state is never changed, only replaced with a new value.

// ❌ Mutation – same reference, React doesn't see the change
todos.push(newTodo); setTodos(todos)
user.name = 'Eve';   setUser(user)

// ✅ New values
setTodos((prev) => [...prev, newTodo])                                     // add
setTodos((prev) => prev.filter((t) => t.id !== id))                        // remove
setTodos((prev) => prev.map((t) => (t.id === id ? { ...t, done: !t.done } : t))) // update
setUser((prev) => ({ ...prev, name: 'Eve' }))                              // object
setItems((prev) => prev.toSorted(byName))                                  // sorting without mutation

📚 In depth in the lesson State and events.

4. Every kind of state has its place

The most common architectural mistake in React is putting state in the wrong place – typically everything into one global store, or server data into useState. It helps to tell what kind of state you have and choose the tool accordingly. As a general rule: keep state as low as you can and lift it only when more components need it.

Kind of state	Example	Where it goes
Local UI state	an open menu, text in an input, hover	`useState`
Shared between siblings	the selected item in a list + the detail	lift it to the nearest common parent
Complex, with many transitions	a 4-step wizard, an editor	`useReducer`
Rarely changing, needed deep down	theme, signed-in user, language	Context
Should survive a reload / be shareable by link	filters, page, sorting, open tab	URL (search params, route params)
Server data	a product list, a profile	TanStack Query (cache)
App-wide client state, changing often	a cart, a document in progress	Zustand / Redux Toolkit

// Lifting state up: two siblings need the same value → it moves to the parent
function Inbox() {
  const [selectedId, setSelectedId] = useState<string | null>(null)
  return (
    <>
      <MessageList selectedId={selectedId} onSelect={setSelectedId} />
      <MessageDetail id={selectedId} />
    </>
  )
}

📚 In depth in the lesson Application state management.

5. Events in handlers, synchronisation in effects

Code in a component has three possible places: render (computing the UI), a handler (reacting to a specific user action) and an effect (synchronising with something outside React). Ask: Why should this code run?

Because the user did something (a click, a submit) → handler.
Because the component appeared and has to be in sync with an external system (a WebSocket, a timer, a DOM API, a non-React library) → effect.
Because something can be computed from the data → render, no effect.

// ❌ An effect as a "reaction to an event" – indirect, fragile, also runs on other changes
const [submitted, setSubmitted] = useState(false)
useEffect(() => {
  if (submitted) {
    post('/api/order', cart)
    showToast('Ordered!')
  }
}, [submitted])

// ✅ The logic belongs where the event happened
async function handleOrder() {
  await post('/api/order', cart)
  showToast('Ordered!')
}

When you do write an effect, it must be able to start and stop: whatever the effect opens, the cleanup closes. Strict Mode runs effects twice on purpose (connect → disconnect → connect) to expose a missing cleanup.

// ✅ Synchronisation with an external system + cleanup + handling a race condition
useEffect(() => {
  const controller = new AbortController()

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((r) => r.json())
    .then(setUser)
    .catch((e) => { if (e.name !== 'AbortError') setError(e) })

  // Does userId change before the response arrives? We cancel the old request,
  // so a slow old response can't overwrite newer data.
  return () => controller.abort()
}, [userId]) // every reactive value the effect reads

📚 In depth in the lesson Effects (useEffect).

6. Refs are an emergency exit

useRef remembers a value between renders, but changing it doesn't trigger a render. That makes it good for things the user doesn't see: a DOM element, a timer ID, a previous value, a library instance. Whatever shows up in the UI belongs in state.

function Stopwatch() {
  const [elapsed, setElapsed] = useState(0)          // ✅ the user sees it → state
  const intervalRef = useRef<number | null>(null)    // ✅ just a technical detail → ref

  const start = () => {
    intervalRef.current = window.setInterval(() => setElapsed((e) => e + 1), 1000)
  }
  const stop = () => {
    if (intervalRef.current !== null) clearInterval(intervalRef.current)
  }
  // …
}

// ❌ A ref instead of state: the value changes, but the screen stays stale
const countRef = useRef(0)
<button onClick={() => countRef.current++}>{countRef.current}</button>

Work with the DOM through a ref only where it can't be done declaratively: focus, scroll, measuring, video playback. In React 19, ref is an ordinary prop, so you no longer need forwardRef.

// React 19: ref as a regular prop
function TextInput({ ref, ...props }: React.ComponentProps<'input'>) {
  return <input ref={ref} {...props} />
}

const inputRef = useRef<HTMLInputElement>(null)
<TextInput ref={inputRef} />
<button onClick={() => inputRef.current?.focus()}>Edit</button>

📚 In depth in the lesson Refs (useRef).

7. Describe what happened, not how to change it

When several handlers change state in different ways, the logic gets spread across the whole component. A reducer puts it in one place: components only report events (card_moved), and the reducer decides how they turn into new state. It's a pure function, so you can test it without any UI and easily add, say, undo.

type Action =
  | { type: 'item_added'; name: string }
  | { type: 'item_toggled'; id: string }
  | { type: 'cleared_done' }

function reducer(state: Item[], action: Action): Item[] {
  switch (action.type) {
    case 'item_added':
      return [...state, { id: crypto.randomUUID(), name: action.name, done: false }]
    case 'item_toggled':
      return state.map((i) => (i.id === action.id ? { ...i, done: !i.done } : i))
    case 'cleared_done':
      return state.filter((i) => !i.done)
  }
}

const [items, dispatch] = useReducer(reducer, [])
dispatch({ type: 'item_toggled', id })   // ✅ "what happened"
// instead of setItems(items.map(...)) scattered across five handlers

useState	useReducer
Simple, independent values	Several values that change together
A few ways the state changes	Many different transitions
The logic is trivial	You want to test or share the logic (e.g. with Context)

📚 In depth in the lesson Complex state (useReducer).

8. Context delivers, it doesn't manage

Context holds no state itself – it only delivers a value deep into the tree without prop drilling. The state still lives in useState/useReducer inside the Provider. Every change of the value re-renders all consumers, so it suits data that changes rarely.

// ✅ The pattern: Provider + a custom hook with a check
const ThemeContext = createContext<Theme | null>(null)

export function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme, setTheme] = useState<'light' | 'dark'>('light')
  const value = useMemo(() => ({ theme, setTheme }), [theme])  // stable reference
  return <ThemeContext value={value}>{children}</ThemeContext>
}

export function useTheme() {
  const ctx = use(ThemeContext)
  if (!ctx) throw new Error('useTheme must be used inside <ThemeProvider>')
  return ctx
}

📚 In depth in the lesson Context.

9. Custom hooks share logic, not state

A custom hook is an ordinary function starting with use that calls other hooks. Every component that calls it gets its own independent copy of the state. A hook isn't for sharing data (that's Context or a store), but for reusing behaviour and naming intent.

function useDebouncedValue<T>(value: T, delay = 300) {
  const [debounced, setDebounced] = useState(value)
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delay)
    return () => clearTimeout(id)
  }, [value, delay])
  return debounced
}

// The component reads like a sentence – what it does, not how
function Search() {
  const [query, setQuery] = useState('')
  const debouncedQuery = useDebouncedValue(query)
  const { data } = useQuery({ queryKey: ['search', debouncedQuery], queryFn: () => search(debouncedQuery) })
  // …
}

📚 In depth in the lesson Custom hooks.

10. Forms: let the platform do the work

Not every field has to be controlled. When you only need the value on submit, leave it in the DOM and read it from FormData. A controlled input (value + onChange) makes sense when you have to react while typing – live validation, formatting, dependent fields.

React 19 Actions add a pending state, errors and optimistic UI on top of that, without hand-written isLoading variables.

async function subscribe(prev: State, formData: FormData): Promise<State> {
  const email = String(formData.get('email'))
  if (!email.includes('@')) return { error: 'Invalid e-mail' }
  await api.subscribe(email)
  return { error: null, done: true }
}

function Newsletter() {
  const [state, formAction, isPending] = useActionState(subscribe, { error: null })
  return (
    <form action={formAction}>
      <input name="email" defaultValue="" />   {/* uncontrolled – that's enough */}
      <button disabled={isPending}>{isPending ? 'Subscribing…' : 'Subscribe'}</button>
      {state.error && <p role="alert">{state.error}</p>}
    </form>
  )
}

📚 In depth in the lesson Forms and React 19 Actions.

11. Performance: structure first, memo later

Rendering isn't expensive – unnecessary DOM changes and heavy computations are. React DOM changes only what differs. Before you start memoising, measure the problem in the React DevTools Profiler and try to solve it with structure:

Move state down – into the component that really needs it. Then only that component re-renders on a change.
Pass content through children – elements created by the parent don't re-render when the state of the wrapping component changes.
Only then memo, useMemo, useCallback (or the React Compiler, which does it for you).

// ❌ Typing into the input re-renders the expensive chart too
function Dashboard() {
  const [query, setQuery] = useState('')
  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ExpensiveChart />
    </>
  )
}

// ✅ State moved down – ExpensiveChart doesn't re-render at all, without a single memo
function Dashboard() {
  return (
    <>
      <SearchBox />          {/* query lives inside */}
      <ExpensiveChart />
    </>
  )
}

Tool	What it does	When
`memo(Comp)`	skips the render when props are the same	an expensive component, often with the same props
`useMemo`	remembers the result of a computation	an expensive computation, or a stable object for memo/a dependency
`useCallback`	remembers a function	the function goes to a memo component or into dependencies
`useTransition`	marks an update as non-urgent	switching a tab, filtering a large list
`useDeferredValue`	a delayed copy of a value	you don’t own the value (a prop), you want a smooth input

📚 In depth in the lesson Performance and rendering.

12. Composition over configuration

A component driven by a dozen props (showHeader, headerIcon, footerButtons…) grows with every new requirement. A component that accepts content through children and slots doesn't have to change at all.

// ❌ Configuration: every new variant = a new prop
<Card title="Order" showIcon icon="cart" footerText="Pay" onFooterClick={pay} />

// ✅ Composition: Card only handles the frame, whoever uses it supplies the content
<Card>
  <Card.Header><CartIcon /> Order</Card.Header>
  <OrderItems />
  <Card.Footer><button onClick={pay}>Pay</button></Card.Footer>
</Card>

More patterns from the same family:

Compound components (Tabs, Tabs.List, Tabs.Panel) – they share state through Context, the user assembles the structure.
Portals – a modal or tooltip is rendered outside the parent's DOM (because of overflow and z-index), but stays in the React tree, so context and events work normally.
Error boundaries – an error in the render of one part doesn't bring down the whole app. They don't catch errors in handlers and async code, though.

📚 In depth in the lesson Component design patterns.

13. Types where nonsense can't be written

TypeScript helps most when a type describes only valid states. Several independent booleans and optional fields allow combinations that make no sense (isLoading and error at the same time). A discriminated union forbids them as you type.

// ❌ 2 × 2 × 2 combinations, only some of them valid
type State = { isLoading: boolean; error?: string; data?: User[] }

// ✅ Only four valid states; in each branch TS knows what is available
type State =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'error'; error: string }
  | { status: 'success'; data: User[] }

switch (state.status) {
  case 'success': return <UserList users={state.data} />   // data is definitely here
  case 'error':   return <p>{state.error}</p>
}

A short syntax cheat sheet:

Syntax	Meaning	Example
`:`	the type of a value (variable, parameter, return value)	`function f(id: string): User`
`<…>`	a generic type argument	`useState<User \| null>(null)`
nothing	let TS infer – where possible, it’s the best choice	`const [n, setN] = useState(0)`
`satisfies`	checks the type but keeps the exact shape	`const routes = {…} satisfies Routes`
`as`	a “trust me” assertion – no runtime check, use sparingly	`el as HTMLInputElement`

// Props, children and events in React
type ButtonProps = React.ComponentProps<'button'> & { variant?: 'primary' | 'ghost' }

function Panel({ title, children }: { title: string; children: React.ReactNode }) { … }

// You don't have to write the event type when the handler is inline – TS infers it
<input onChange={(e) => setName(e.target.value)} />

// A generic component: the relation between items and renderItem is held by the type T
function List<T>({ items, renderItem }: { items: T[]; renderItem: (item: T) => React.ReactNode }) { … }

📚 In depth in the lesson Where to write a type.

📚 In depth in the lesson TypeScript with React.

14. The URL is state too

Everything that should survive a page refresh, the Back button or sending a link to a colleague belongs in the URL – not in useState. Typically: the current page, the detail ID, filters, sorting, search, the open tab.

// ❌ The filter is lost on reload and can't be shared
const [category, setCategory] = useState('all')

// ✅ The filter in search params: /products?category=shoes&sort=price
const [params, setParams] = useSearchParams()
const category = params.get('category') ?? 'all'

const changeCategory = (c: string) =>
  setParams((prev) => { prev.set('category', c); return prev })

Route params (/products/:id) identify what is displayed, search params adjust how.
Nested routes with <Outlet /> share a layout; a loader and an error element apply only to their part of the page.
Navigate with a link (<Link>), use navigate() only after an action (e.g. after saving).

📚 In depth in the lesson Routing (React Router).

15. Server data is a cache

Data from the server isn't your state – it's a copy of something that belongs to the server and can change there at any moment. It needs caching, request deduplication, retry on error, a refresh when you return to the window and invalidation after a change. Written by hand in useEffect you'll get it wrong; that's why TanStack Query (and similar libraries) exist.

// ✅ queryKey contains EVERYTHING the query depends on → a change = a new query/cache entry
const { data, isPending, error } = useQuery({
  queryKey: ['products', { category, page }],
  queryFn: () => api.products({ category, page }),
  staleTime: 60_000,   // treat the data as fresh for a minute
})

// ✅ After a change on the server, invalidate the affected data, the UI refreshes by itself
const queryClient = useQueryClient()
const addProduct = useMutation({
  mutationFn: api.createProduct,
  onSuccess: () => queryClient.invalidateQueries({ queryKey: ['products'] }),
})

📚 In depth in the lesson Loading data.

Putting it into practice: how to approach a new feature

The principles work best when you go through them in this order – that's exactly how the final project came about:

Data and types. What data exists? Describe it with types, states as discriminated unions.
Minimal state. What of it is really state? What is derived? Where does each piece of state live (locally, URL, server, store)?
Logic without UI. State transitions (a reducer, mutations) as pure functions.
Static UI. Components that only display data from props. Split by responsibility, assembled by composition.
Interactivity. Handlers wired to actions; effects only for synchronising with the outside world.
Performance last. Only when the problem is measurable.

Quick decisions

Situation	Reach for…	Not for…
A value can be computed from other data	a computation during render	useState + useEffect
The user clicked and something should happen	code in a handler	an effect watching a flag
Hooking up a WebSocket, timer, DOM API	useEffect with cleanup	code directly in render
A value the user doesn’t see (a timer ID)	useRef	useState
Many different changes to one piece of state	useReducer	five setters in handlers
A theme / user needed deep in the tree	Context	prop drilling through 6 levels
A filter that should survive a reload	search params	useState
Data from an API	TanStack Query	fetch in useEffect
A slow render	the Profiler, then moving state down	memo everywhere “just in case”
A component with 15 props	composition via children	one more boolean

Check yourself

Quiz You have products in state and need to display the total price. What do you do?

Add const [total, setTotal] = useState(0) and recompute it in a useEffect when products changes.Compute const total = products.reduce(…) directly during render.Store the total in Context so it is available everywhere.

Quiz After clicking “Save” the form should be submitted and a notification shown. Where does this code belong?

In a useEffect that watches an isSaved flag.In the button’s handler (or in a form action).In the component body, so it runs during render.

Quiz A product list has a category filter. Users want to send each other links to the filtered list. Where should the filter live?

in the useState of the list componentin a Zustand storein the URL search params

Quiz Typing into the search field is slow because a big table next to it re-renders on every character. What do you try first?

Wrap all components in memo and all functions in useCallback.Measure it in the Profiler and move the search state into the component that really needs it.Rewrite the state in Redux.

Summary

UI = f(state). Rendering is a pure computation; think in states, not in steps.
Minimal state, one source of truth, compute derived values during render.
State is a snapshot – change it by replacing, use an updater when depending on the previous value.
Every kind of state has a place: local, lifted, Context, URL, server cache, store.
Events → handler, synchronisation → effect (with cleanup and complete dependencies).
Refs for values the user doesn't see; a reducer for many transitions; Context only delivers.
Custom hooks share behaviour, not data.
Performance: measure, move state down, use children, only then memo.
Composition instead of configuration props; types that don't allow an invalid state.
The best React code is the simplest code that correctly does what it should.

Loading lesson…

💬 Found a mistake, something unclear, or have an idea? Let me know.