Go from building components to shipping production front-ends: architecture, TypeScript, state, performance, testing, CI and code review.

Front-End Engineering

## Why it matters

Every product team eventually notices it has eleven slightly different buttons, four modal implementations and three shades of "primary blue". A **component library** (the code half of a design system) fixes this: one well-built Button, Input or Modal that everyone uses. Fix a focus bug once and it is fixed on every page. As a mid-level front-end developer you will both consume a component library and contribute to it, so you need to know what makes a component good to reuse.

## What a design system contains

- **Design tokens**: named values for colour, spacing, radius, type and motion, such as `--color-primary` or `--space-4`. Components use tokens, never raw hex codes, so a theme or dark mode is a token swap.
- **Primitives**: Button, Input, Select, Checkbox, Modal, Tabs, Tooltip. They are accessible and unopinionated about business logic.
- **Patterns and docs**: how to compose primitives into forms, empty states and page headers, usually documented in a tool such as Storybook with live examples.

You do not always build primitives from scratch. Headless libraries (Radix UI, React Aria, Headless UI) supply the hard keyboard and ARIA behaviour; your library adds the styling and the API your team needs.

## A good component API

A reusable component is a contract. Good contracts are small, predictable and hard to misuse.

1. **Start from the native element.** A button is a `<button type="button">`, not a `div` with a click handler. You get focus, Enter and Space, disabled behaviour and the right role for free.
2. **Variants, not style props.** Offer `variant: "primary" | "secondary" | "danger"` and `size: "sm" | "md"`, mapped to classes. Avoid `color` and `padding` props that let every caller reinvent the design.
3. **Pass through native attributes.** In React, spread the rest of the props onto the element (`...rest`) and forward the ref, so callers can add `aria-describedby`, `form`, `data-testid` or focus it programmatically.
4. **Make accessibility required where it matters.** An icon-only button has no visible text, so its accessible name must come from somewhere. Make `aria-label` required for that case, in the types and with a development-time error.
5. **Visible focus by default.** Never ship `outline: none` without a `:focus-visible` replacement.
6. **Consistent states.** Hover, active, focus-visible, disabled and loading look the same on every variant and are driven by tokens.

In React and TypeScript the shape looks like this:

```tsx
type ButtonProps = React.ComponentPropsWithoutRef<"button"> & {
  variant?: "primary" | "secondary";
  icon?: React.ReactNode;
} & ({ children: React.ReactNode } | { children?: never; "aria-label": string });

export const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
  function Button({ variant = "primary", icon, children, className, type = "button", ...rest }, ref) {
    return (
      <button ref={ref} type={type} className={cx("btn", `btn--${variant}`, className)} {...rest}>
        {icon && <span aria-hidden="true">{icon}</span>}
        {children}
      </button>
    );
  }
);
```

The union at the end says: either you pass visible children, or you pass an `aria-label`. TypeScript then refuses `<Button icon={<XIcon />} />` with no name.

## Disabled, loading and links

- **Disabled.** The native `disabled` attribute removes the button from the tab order and blocks clicks. If users need to discover why an action is unavailable, consider keeping it focusable with `aria-disabled="true"` and explaining the reason nearby.
- **Loading.** Keep the button's width stable (no layout shift), show a spinner with an accessible status message, and prevent double submits.
- **Links that look like buttons.** Navigation is a link (`<a href>`); actions are buttons. A library often lets `Button` render an anchor when given `href`, keeping one visual style with the right semantics.

## Versioning and change

A shared component is used in hundreds of places, so changes need care:

- Add props in a backward-compatible way; deprecate before removing.
- Use semantic versioning if the library is a package: breaking changes bump the major version.
- Cover each component with tests (role, name, keyboard, states) and visual examples, so a refactor does not quietly break focus rings everywhere.

## Common mistakes

- **Div buttons** that cannot be reached by keyboard.
- **Unlimited style props** (`bg`, `px`, `rounded`), which turn the library into an inline-style generator.
- **Swallowing native props**, so callers cannot add `aria-*` attributes or a ref.
- **Icon buttons with no name**, announced only as "button".
- **Business logic inside primitives**, such as a Button that checks user permissions.
- **Hard-coded colours** instead of tokens, which breaks dark mode.

## Quick recap

- A component library gives one accessible, tested implementation of each primitive, styled with tokens.
- Build on native elements, expose variants rather than style props, pass through native attributes and refs.
- Make accessible names mandatory for icon-only controls and always provide a visible focus style.
- Treat changes as API changes: backward compatible, versioned and tested.

## Try it

In the Do tab, turn a div-based button into a reusable `createButton` factory with variants, an icon-only mode that requires a label, and a proper focus style.


Build a reusable, accessible button with a small, predictable API.

Component libraries

Accessible building blocks for web: buttons

Why you shouldn't use a div for everything - creating accessible buttons and navigations

## Why it matters

Tests are how a team changes code quickly without fear. But a test suite can also slow you down: flaky end-to-end tests that fail at random, snapshot files nobody reads, unit tests that break every time you rename a variable. A mid-level developer is expected to decide **what** to test and **at which level**, not just how to write a test.

## The levels

**Static checks** catch whole classes of bugs before anything runs: TypeScript, ESLint (including accessibility rules such as `eslint-plugin-jsx-a11y`) and formatting. They are the cheapest tests you have.

**Unit tests** check one function or small module in isolation, in milliseconds. Use them for pure logic with many cases: price formatting, validators, reducers, date maths.

```ts
import { describe, it, expect } from "vitest";
import { formatPrice } from "./formatPrice";

describe("formatPrice", () => {
  it("formats cents as dollars", () => {
    expect(formatPrice(1999, "USD")).toBe("$19.99");
  });
  it("shows free for zero", () => {
    expect(formatPrice(0, "USD")).toBe("Free");
  });
});
```

**Integration (component) tests** render a component, or a few working together, in a simulated DOM (jsdom) and interact with it the way a user would. With React Testing Library you find elements by **role and accessible name**, which doubles as an accessibility check:

```tsx
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

it("shows an error when the email is invalid", async () => {
  render(<SignupForm onSubmit={vi.fn()} />);
  await userEvent.type(screen.getByLabelText(/email/i), "not-an-email");
  await userEvent.click(screen.getByRole("button", { name: /sign up/i }));
  expect(screen.getByRole("alert")).toHaveTextContent(/valid email/i);
});
```

Network calls are mocked at the boundary (for example with MSW, Mock Service Worker), so the test exercises your real components, hooks and state together.

**End-to-end (e2e) tests** drive a real browser against a running app, usually with Playwright or Cypress. They prove that the whole system works: routing, cookies, the real API, the build. They are the slowest and most fragile, so keep them for **critical journeys**: sign up, log in, checkout, complete a lesson.

```ts
import { test, expect } from "@playwright/test";

test("learner can complete a lesson", async ({ page }) => {
  await page.goto("/courses/react-fundamentals");
  await page.getByRole("link", { name: "Components and props" }).click();
  await page.getByRole("button", { name: "Mark complete" }).click();
  await expect(page.getByText("Lesson complete")).toBeVisible();
});
```

## Shape of a healthy suite

You may have seen the **testing pyramid** (many unit tests, fewer integration, few e2e) and the **testing trophy** (static checks at the base, with integration tests as the largest layer). For UI code the trophy is a good default: component-level integration tests give the most confidence per minute, because they test what the user sees without the cost of a full browser.

A practical plan for a feature:

1. Types and lint on everything (free once set up).
2. Unit tests for tricky pure logic.
3. Integration tests for each component's main behaviours: renders the data, handles empty, loading and error, responds to keyboard and clicks.
4. One or two e2e tests for the journey the business cares about.
5. Optional: automated accessibility checks (axe in component or e2e tests) and visual regression screenshots for the design system.

## What makes a good test

- **Tests behaviour, not implementation.** Assert on what the user sees and can do, not on internal state or which hook was called. Then refactors do not break tests.
- **Finds elements like a user**: by role, label and text, not by CSS class or test id unless there is no better option.
- **Is deterministic.** Control time, random values and network. Wait for conditions (`await expect(...).toBeVisible()`), never for fixed sleeps.
- **Is independent.** Each test sets up its own data and can run alone or in any order.
- **Fails for one reason**, with a name that describes the behaviour: "shows an error when the email is invalid".

## Worked example: planning tests for a search box

A course search box debounces input, calls `/api/courses?q=`, shows results, an empty message, and an error state.

- Unit: the `buildSearchUrl(q, filters)` helper, including encoding and empty filters.
- Integration: typing shows results from a mocked API; no results shows "No courses match"; a 500 shows an alert; the results list is announced (an `aria-live` region); arrow keys move through suggestions.
- E2e: none just for this; it is covered by the existing "find and start a course" journey.

## Common mistakes

- **Testing implementation details**, such as a component's internal state, so every refactor breaks tests.
- **Too many e2e tests**, making CI slow and flaky.
- **Large snapshot tests** that people update without reading.
- **Fixed waits** (`waitForTimeout(2000)`) that are slow on fast machines and flaky on slow ones.
- **Mocking everything**, so the test only proves the mocks work.
- **Chasing 100 percent coverage** instead of covering the risky behaviour.

## Quick recap

- Static checks, unit, integration and e2e tests each catch different bugs at different costs.
- For UI, put most effort into integration tests that use roles and labels; keep e2e for critical journeys.
- Test behaviour, keep tests deterministic and independent, and wait for conditions rather than time.

## Try it

Open the Do tab and decide where several tests belong.


Plan which behaviour to cover with unit, integration and end-to-end tests.

Testing strategy

Kent C. Dodds – Write tests. Not too many. Mostly integration.

Get started with end-to-end testing: Playwright | Episode 1 - Introduction

## Why it matters

Good motion explains what happened: a menu grows from the button that opened it, a toast slides in from where it will live, a checkmark confirms a save. Bad motion is slow, janky, or makes people feel sick. Some users with vestibular disorders get dizziness or nausea from large movement on screen, and WCAG asks that motion triggered by interaction can be turned off (Success Criterion 2.3.3, Animation from Interactions, level AAA) and that anything moving for more than five seconds can be paused (2.2.2, level A).

Motion is also a performance problem. An animation that drops frames makes an app feel broken even when it works.

## Why transform and opacity

To draw a frame, the browser may do three kinds of work:

1. **Layout**: work out the size and position of every affected box.
2. **Paint**: fill in the pixels of those boxes.
3. **Composite**: stack the painted layers together, often on the GPU.

Animating `width`, `height`, `top`, `left`, `margin` or `padding` changes geometry, so the browser may redo layout and paint on every frame, for the element and everything around it. Animating **`transform`** (translate, scale, rotate) and **`opacity`** can usually be handled in the composite step alone, which is cheap and smooth even on modest phones.

```css
/* Janky: layout every frame, and 'all' animates anything that changes */
.panel { transition: all 0.8s; left: -320px; }
.panel.is-open { left: 0; }

/* Smooth: compositor-friendly properties, named explicitly */
.panel {
  opacity: 0;
  transform: translateY(-8px) scale(0.98);
  transition-property: opacity, transform;
  transition-duration: 200ms;
  transition-timing-function: cubic-bezier(0.2, 0, 0, 1);
}
.panel.is-open { opacity: 1; transform: none; }
```

Never write `transition: all`. It animates properties you did not intend (including layout ones), and a later change to the element can suddenly become a slow animation.

Note that modern CSS also has standalone `translate`, `scale` and `rotate` properties. They are composited too, but you must transition the property you actually change: transitioning `transform` does nothing if your code sets `scale`.

To animate height, such as an accordion, prefer a technique that avoids per-frame layout of the whole page: animate a `grid-template-rows` from `0fr` to `1fr` on a small container, or scale and fade the content, and keep the duration short.

## Timing that feels right

- **Short.** Most UI transitions are 100–300 ms. Small things (a hover colour, a checkbox) are near the low end; larger moves (a sheet sliding in) near the high end. Anything over about 500 ms feels slow for a routine action.
- **Easing.** Entering elements decelerate (ease-out); exiting elements accelerate (ease-in) and can be a little faster than they entered.
- **Tokens.** Put durations and easings in CSS custom properties (`--motion-fast: 150ms`) so the whole app moves consistently and you can tune it in one place.
- **Purpose.** If you cannot say what an animation communicates (where something came from, what changed, that an action succeeded), remove it.

## Respecting reduced motion

Operating systems have a "reduce motion" setting, exposed to CSS as a media query:

```css
@media (prefers-reduced-motion: reduce) {
  .panel {
    transform: none;                  /* no movement */
    transition-property: opacity;     /* a quick fade is still fine */
    transition-duration: 150ms;
  }
}
```

Reduced motion does not have to mean no feedback. Replace movement (slides, zooms, parallax, spinning) with a short fade or an instant change. Keep essential indicators such as a loading spinner, and remove decorative effects like confetti entirely.

JavaScript animations (scrolling, canvas, the Web Animations API) need the same check:

```js
function prefersReducedMotion() {
  return window.matchMedia("(prefers-reduced-motion: reduce)").matches;
}

target.scrollIntoView({ behavior: prefersReducedMotion() ? "auto" : "smooth" });
```

To test it, turn on Reduce Motion in your operating system settings, or use DevTools: Rendering panel > Emulate CSS media feature prefers-reduced-motion.

## Accessibility of animated components

Motion must not break the component's semantics. A menu that fades out is still in the DOM and still focusable while invisible unless you stop that. Mark the closed panel `inert` (or `hidden` after the exit finishes) so keyboard and screen reader users cannot land in an invisible menu, and keep `aria-expanded` on the toggle in sync with the real state.

## Common mistakes

- `transition: all`, or animating `width`, `left` or `height` on large elements.
- Durations of a second or more for everyday actions.
- Ignoring `prefers-reduced-motion`, or handling it by disabling every transition including focus and colour feedback.
- Invisible but focusable panels after a fade-out.
- Motion that only plays on page load and delays content the user came for.

## Quick recap

- Animate `transform` and `opacity` (or `translate`/`scale`/`rotate`), named explicitly; never `transition: all`.
- Keep transitions short (about 100–300 ms) with consistent, tokenised easings.
- Under `prefers-reduced-motion: reduce`, replace movement with a fade or an instant change, in CSS and JavaScript.
- Keep semantics in sync: `aria-expanded`, and `inert` or `hidden` on closed content.

## Try it

In the Do tab, rework a janky menu animation so it uses only compositor-friendly properties, respects reduced motion, and keeps its ARIA state correct.


Animate only transform and opacity, keep motion short and purposeful, and respect reduced motion.

Motion with restraint

The Only 2 CSS Properties You Should Animate *

WTF is prefers reduced motion!?!

Build reusable accessible components, plan a balanced test suite, and add motion that is smooth and respects user settings.