
## Props are inputs

Props are read-only values supplied by a parent. They let a component be reused with different data. Do not mutate props; if a value needs to change in response to user interaction, identify the component that should own that state.

```jsx
function Topic({ name, level }) {
  return <li>{name} — {level}</li>;
}
```

## Render a collection

Use `map` to turn data into elements. Give each sibling a stable key that identifies the item across updates. Keys help React associate each item with its previous instance; an array index is a poor key when items can be inserted, deleted, or reordered.

```jsx
const topics = [
  { id: 'state', name: 'State', level: 'core' },
  { id: 'effects', name: 'Effects', level: 'advanced' },
];

function TopicList() {
  return (
    <ul>
      {topics.map((topic) => (
        <Topic key={topic.id} name={topic.name} level={topic.level} />
      ))}
    </ul>
  );
}
```

## Conditional UI

Use ordinary JavaScript expressions for loading, empty, error, and success states. Decide what a user should see in each state instead of rendering a blank area when data is missing.

```jsx
function Results({ items, isLoading }) {
  if (isLoading) return <p>Loading results…</p>;
  if (items.length === 0) return <p>No results yet.</p>;
  return <ul>{items.map((item) => <li key={item.id}>{item.name}</li>)}</ul>;
}
```

**Exercise:** Render a list of learning goals, add an empty state, then reorder or remove an item. Verify that keys use stable item IDs.


Pass data into components and render collections and alternate states predictably.

Props, lists, and conditional UI


## What React does

React is a JavaScript library for describing user interfaces as a tree of components. A component receives inputs, commonly called props, and may read state. It returns a description of what should appear. When relevant inputs change, React renders again and updates the affected parts of the page.

```jsx
function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}
```

The component is a function. Its return value describes the UI; React handles creating and updating the DOM. This is a declarative approach: describe the result for the current data instead of manually issuing DOM commands for every change.

## Render is not the same as mount

A render means React calls components to calculate the next UI. It does not necessarily mean every DOM node is recreated. React compares the new description with the current one and commits the necessary changes. Rendering should therefore be pure: for the same props and state, return the same UI and do not mutate external data.

```jsx
function CounterLabel({ count }) {
  return <p>You clicked {count} times.</p>;
}
```

Avoid changing a global variable, making a network request, or modifying the DOM while rendering. Those actions belong in event handlers or, when appropriate, an effect.

## Try it

Start with a small React app in the linked sandbox. Make a `Greeting` component, render it from `App`, and change the name prop. Notice that changing data changes the description React renders.

**Exercise:** Add a second component that displays a short list of favorite topics. Keep its output a pure function of its props.

**Check your understanding:** What should a component return for the same props and state? What kinds of work should not happen during render?


Understand declarative UI, rendering, and the component tree before writing application code.

The React mental model


## JSX describes UI

JSX is syntax that lets JavaScript describe a tree of UI elements. It is not a string of HTML. Use curly braces to insert JavaScript expressions, and remember that JSX attributes use JavaScript naming such as `className`.

```jsx
function ProfileCard() {
  const name = 'Ada';
  return (
    <article className="profile-card">
      <h2>{name}</h2>
      <p>Engineer and mathematician</p>
    </article>
  );
}
```

Components begin with a capital letter, can use other components, and should be small enough to explain in a sentence. A useful boundary often corresponds to a visual or behavioral responsibility, not every individual HTML tag.

## Compose instead of building giant components

Pass a nested UI through the `children` prop when a component owns layout or behavior but not the content:

```jsx
function Panel({ title, children }) {
  return (
    <section>
      <h2>{title}</h2>
      {children}
    </section>
  );
}

function App() {
  return <Panel title="Getting started"><p>Build one piece at a time.</p></Panel>;
}
```

Keep components focused. Avoid a single component that owns unrelated page sections, fetching, form state, and formatting. Extract a component when it clarifies a responsibility or can be reused—not just to reduce line count.

## Exercise

Create `PageHeader`, `ProfileCard`, and `Panel` components. Compose them in `App`. Add a prop to `ProfileCard` and render two profiles with different values.


Break a page into cohesive components and compose them through JSX.

Components, JSX, and composition


## State remembers information between renders

Use a state hook for values that change over time and affect what the component displays. Calling the setter requests another render. Do not assign directly to a state variable or mutate an object held in state.

```jsx
import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount((current) => current + 1)}>Count: {count}</button>;
}
```

The updater function is useful when the next value depends on the previous one. For objects, create a new object with the changed fields rather than editing the old one in place.

## Events and controlled forms

Pass a function to event props such as `onClick` or `onChange`. For a controlled input, the displayed value comes from state and each change updates that state:

```jsx
function NameForm() {
  const [name, setName] = useState('');
  return (
    <label>
      Name
      <input value={name} onChange={(event) => setName(event.target.value)} />
    </label>
  );
}
```

Use a real `<form>` and handle its `onSubmit` for form submission. Validate user input, communicate errors in text, and use labels so controls are usable with assistive technology.

## Exercise

Build a short task list. Add a task through a form, clear the input after submission, and remove a task by its stable ID. Keep the array immutable when adding or removing items.


Model changing UI with state and respond to user actions without mutating data.

State, events, and forms


## Keep state close to where it is used

Start with the component that needs a value. If sibling components need the same state, move it to their nearest common parent and pass the value and event handlers as props. This is called lifting state up. Avoid duplicating a value in multiple places when one source of truth will do.

## Context is for shared values

Context lets a parent provide a value to descendants without threading it through every intermediate component. It can help with values such as the current theme or signed-in user. It is not automatically a better replacement for props: keep simple, local data local.

```jsx
const ThemeContext = createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}
```

## Reducers make transitions explicit

When several actions update related state, use a reducer to define the transition from current state and action to next state:

```jsx
function reducer(state, action) {
  switch (action.type) {
    case 'added':
      return [...state, action.task];
    case 'removed':
      return state.filter((task) => task.id !== action.id);
    default:
      return state;
  }
}
```

Reducers should be pure and return new values. Do not use context or a reducer solely to make a small component appear more abstract.

**Exercise:** Add a filter to the task list. Decide which component owns the filter and which components need to read it. Use a reducer only if the set of transitions benefits from being centralized.


Place state near its users, share it deliberately, and model complex transitions with a reducer.

State ownership, context, and reducers


## Effects synchronize with external systems

An effect runs after rendering to synchronize with something outside React: a browser API, subscription, or network connection. Most calculations based on props or state do not need an effect; calculate them during render instead.

```jsx
useEffect(() => {
  document.title = `Tasks: ${tasks.length}`;
}, [tasks.length]);
```

If an effect creates a subscription, timer, or listener, return a cleanup function. Dependencies describe the reactive values the effect reads. Do not silence dependency problems with an empty array; restructure the effect or include the required dependencies.

## Refs hold non-rendering values

A ref can retain a value between renders without triggering a render when it changes. DOM refs are useful for focus, measurement, and integrations with imperative APIs. If a value should change the visible UI, it usually belongs in state, not a ref.

## Fetching requires UI states and cleanup

When fetching manually, model loading, success, and error states. Prevent an obsolete response from updating the UI after the request or component is no longer current. Framework data APIs or server-state libraries may provide a better solution for caching, retries, and synchronization.

```jsx
useEffect(() => {
  const controller = new AbortController();
  setStatus('loading');

  fetch('/api/items', { signal: controller.signal })
    .then((response) => {
      if (!response.ok) throw new Error('Request failed');
      return response.json();
    })
    .then((items) => {
      setItems(items);
      setStatus('success');
    })
    .catch((error) => {
      if (error.name !== 'AbortError') setStatus('error');
    });

  return () => controller.abort();
}, []);
```

**Exercise:** Show loading, error, empty, and populated states. Then compare this small example with a framework's built-in data-loading approach.


Synchronize with external systems when needed, and represent asynchronous UI states explicitly.

Effects, refs, and data fetching


## Custom hooks share behavior

A custom hook is a function whose name starts with `use` and that can call other hooks. It can package reusable behavior, not a separate component instance or shared state by itself.

```jsx
function useWindowWidth() {
  const [width, setWidth] = useState(0);

  useEffect(() => {
    const updateWidth = () => setWidth(window.innerWidth);
    updateWidth();
    window.addEventListener('resize', updateWidth);
    return () => window.removeEventListener('resize', updateWidth);
  }, []);

  return width;
}
```

Call hooks at the top level of components or other hooks, not in conditions or loops. Extract a hook when it makes behavior easier to reuse or reason about.

## Server state has different needs

UI state such as an open menu is usually local and short-lived. Server state is remote, asynchronous, can become stale, and may be shared by many views. A data-fetching library can manage caching, invalidation, retries, and background refreshes—but adds a dependency and concepts to learn.

This portfolio has an existing article introducing [React Query](/blogs/react-query). Use the official TanStack Query documentation in the course references for current setup instructions.

**Exercise:** Extract the resize listener into a custom hook. Then identify which values in a sample app are local UI state and which are server state.


Reuse stateful behavior with hooks and distinguish remote server data from local UI state.

Custom hooks and server state


## Start with a measurement

An additional memoization layer can make code harder to understand and may not improve the experience. First reproduce a user-visible slowdown and use browser tools or React Developer Tools to find the expensive work.

Common sources include rendering a very large list, repeated expensive calculations, unnecessary state placed too high in the tree, and network or image loading—not just component render count.

## Keep updates focused

State location influences how much of the component tree must respond to an update. Keep state near the components that use it. For large collections, consider pagination or virtualization. For expensive calculations, consider memoization after measuring.

```jsx
const visibleItems = useMemo(
  () => items.filter((item) => item.name.includes(query)),
  [items, query],
);
```

`useMemo` caches a calculation between renders when its dependencies are unchanged. It is an optimization, not a correctness mechanism. `memo` and `useCallback` are also tools to apply based on a measured need, not defaults for every component and function.

**Exercise:** Render a large list, profile it, and compare a straightforward implementation with a measured optimization. Record the user-visible improvement, if any.


Measure first, then choose targeted optimizations for expensive rendering work.

Performance and rendering


## Test behavior users rely on

Prefer tests that interact with the interface the way a user does: find a labeled input, type, submit, and verify the visible result. Avoid making every test depend on internal component state or implementation details.

```jsx
render(<NameForm />);
await user.type(screen.getByRole('textbox', { name: /name/i }), 'Ada');
await user.click(screen.getByRole('button', { name: /save/i }));
expect(screen.getByText('Saved Ada')).toBeInTheDocument();
```

The example uses Testing Library concepts. This portfolio already has an article about [React Testing Library](/blogs/react-testing-library).

## Accessibility is part of implementation

Use semantic elements, visible labels, keyboard-operable controls, meaningful link text, and clear status/error messages. Do not use a clickable `div` when a button is the appropriate control. Ensure focus remains visible and color is not the only way to communicate meaning.

## Errors should be visible and recoverable

Show a useful message when an action fails and, when appropriate, allow the user to retry. Error boundaries can catch rendering errors in descendant components; they do not replace handling rejected network requests or form validation.

**Exercise:** Add a test for a failed submission and check that the error is associated with the relevant form control and announced accessibly.


Test meaningful behavior, use semantic HTML, and make failures understandable to users.

Testing, accessibility, and errors


## React is part of a larger system

Production applications also need routing, data loading, forms, accessibility, error reporting, security, deployment, and performance budgets. React itself does not prescribe every decision. A framework may provide routing, server rendering, static generation, and data conventions; a smaller client-only app may not need that complexity.

Choose based on the product and team: rendering needs, accessibility expectations, hosting constraints, data sources, performance, and maintenance. Understand the trade-offs before adding a state library, design system, or abstraction.

## Review the course concepts

- Components describe UI from their inputs; rendering stays pure.
- Props pass data down, while state belongs at the lowest common owner that needs it.
- Effects synchronize with external systems; they are not a general-purpose place for derived values.
- Server state has caching and consistency concerns beyond local UI state.
- Tests should protect user-visible behavior, and semantic HTML improves both accessibility and testability.
- Measure performance before adding optimizations.

## Next steps

Choose a small project and make it complete: define the user problem, sketch the UI, model state, implement loading and error cases, test key flows, and deploy it. Revisit the course references for current APIs and framework-specific guidance. The [course reference list](/courses/react-basics-to-advanced#references) is a good starting point.

**Final exercise:** Build a searchable, accessible list backed by remote data. Include loading, empty, error, and success states; test a core user flow; then profile it before deciding whether any optimization is needed.


Choose architecture and framework features based on product needs, then plan what to learn next.

Production decisions and next steps


## How to use this course

Work through the chapters in order, try the examples in your own editor, and adapt each exercise rather than only copying it. Chapters link to an external React sandbox; no code is sent to or run by this portfolio. Your highlights and notes are stored in this browser only, separately for each chapter.

You should know JavaScript functions, arrays, objects, modules, and basic HTML before starting. TypeScript is useful but not required; examples use JavaScript so the React concepts stay in focus.

The course introduces core React before discussing libraries and production choices. It does not prescribe one framework, state library, or project structure for every application. Check the current official documentation when working with a specific React version.


Build a practical mental model of React, then progress from components and state to data fetching, testing, performance, and production-ready UI architecture.

The official step-by-step guide and interactive examples.

React documentation: Learn React

Components, hooks, and APIs covered in the course.

React documentation: API reference

A practical approach to component boundaries and state.

Thinking in React

Review the JavaScript fundamentals used throughout.

MDN: JavaScript Guide

Why tests should resemble the way people use software.

Testing Library: Guiding Principles

A server-state library for applications that need it.