Topic

Hands-on practice: build mini-projects

Definition

Hands-on practice is a set of small, self-contained coding projects — each with explicit deliverables and acceptance criteria — that together exercise every layer of the frontend track: HTML/CSS foundations, React UI, state and Effects, Redux Toolkit, TanStack Query, and the Next.js App Router.

In simpler words

You build several different small apps. Each one targets a different slice of frontend skills, so finishing all of them proves you can build a real UI end to end.

These are deliberately NOT the Notes capstone. The Notes UI is your single end-of-week build; this topic is a varied menu of standalone apps (inspired by the roadmap.sh React/Next project lists in the navbar) so you practice the same concepts in fresh contexts.

Open live example →

After this you can

Build accessible, responsive UI with semantic HTML and CSS layout
Write correct React components with props, state, lists, and events
Use Effects and refs safely for timers and external synchronization
Separate Redux Toolkit client state from TanStack Query server/API data
Host a UI in the Next.js App Router with correct Server/Client boundaries

How to work these projects

Definition

A staged practice set asks you to implement bounded, demoable deliverables, each mapped to specific curriculum concepts, and to prove them in the browser with Network tab and DevTools evidence rather than only a happy-path screenshot.

In simpler words

Finish one project before the next. Each app is standalone — a separate folder or route is fine.

Done means: the feature works, loading/empty/error states are honest, keyboard and focus behaviour is reasonable, and a short README lists how to run it plus which topics it covers.

From the Quiz app onward, Redux Toolkit owns client-only state (drafts, selection, UI chrome) and TanStack Query owns server/API data — never both.

Do not put JWTs in localStorage. Send cookies with Axios withCredentials when a project uses your own backend.

Use free public APIs where noted (Open-Meteo for weather, Open Trivia DB for quiz questions, the GitHub REST API) so you can build without your own backend.

Project 1 — Portfolio landing page (HTML & CSS foundations)

Definition

A static, responsive multi-section landing page built with semantic HTML and modern CSS layout — no framework — demonstrating document structure, the box model, Flexbox, CSS Grid, and responsive design.

In simpler words

Build a good-looking, responsive page by hand before adding any React.

Deliverables: semantic landmarks (header/nav, hero, projects grid, about, contact footer); a Flexbox nav and a CSS Grid card layout; a mobile breakpoint with no horizontal scroll; visible focus styles and readable contrast.

Topics covered: HTML structure and semantics, the box model, positioning, Flexbox, CSS Grid, responsive design, basic accessibility.

Prep for React: spot the repeated block (a project card) that becomes a reusable component in Project 2.

Acceptance checklist — Project 1

- [ ] Page uses semantic landmarks (header, nav, main, footer)
- [ ] Nav is a Flexbox row; project cards use CSS Grid
- [ ] Layout reflows cleanly at a mobile breakpoint (no horizontal scroll)
- [ ] Images have alt text; interactive elements have visible focus styles
- [ ] Colour contrast is readable (roughly WCAG AA)

Foundations first — a component library cannot rescue a broken box model.

Project 2 — Flash cards (React fundamentals)

Definition

A flash-card study app built from React components with props, conditional rendering, lists with stable keys, event handlers, and local useState — no Redux or Query yet.

In simpler words

Turn a deck of cards into components. Flip, navigate, and add cards using only local React state.

Deliverables: Card, Deck, and CardForm components; flip to reveal the answer (conditional rendering); next/previous navigation; add/edit/delete cards in local state; a distinct empty-deck view; controlled form inputs.

Topics covered: components, JSX, props, conditional rendering, lists and stable keys, events, controlled inputs, useState, the render/commit mental model.

Prep for state tools: notice the “draft card text” and “current card index” — exactly the client-only values that move into Redux Toolkit next.

Acceptance checklist — Project 2

- [ ] Cards render from an array with stable keys (not index if you reorder/delete)
- [ ] Flip toggles the answer via conditional render, not DOM mutation
- [ ] Handlers are passed, not called during render
- [ ] Empty deck is a distinct state from a deck with cards
- [ ] Draft text + current index are obvious state values (ready to lift into RTK)

UI correctness and handler discipline first; stores arrive next.

Project 3 — Pomodoro timer (state, Effects & refs)

Definition

A Pomodoro productivity timer that uses useEffect to drive an interval, cleanup to clear it, functional state updates to avoid stale closures, and useRef for values that must persist without triggering re-renders.

In simpler words

Build a work/break countdown. Getting the timer right is the classic place beginners create stale-closure and cleanup bugs.

Deliverables: start/pause/reset controls; automatic switch between work and break intervals; configurable durations; a useEffect interval with proper cleanup; the functional updater form (setSeconds(s => s - 1)); an optional custom useInterval hook; a document title/badge updated via Effect.

Topics covered: useState, useEffect, cleanup functions, dependency arrays, useRef, stale closures, deriving values during render, custom hooks.

This directly reinforces the Week 4 “stale state and Effects” challenge — build it, then re-read that challenge.

Acceptance checklist — Project 3

- [ ] Interval is created in useEffect and cleared in its cleanup
- [ ] Countdown uses the functional updater (no stale closure freezing at one value)
- [ ] Changing the duration does not leak or duplicate intervals
- [ ] Pause/resume keeps the correct remaining time
- [ ] No setInterval left running after unmount

The timer is small on screen but exercises the trickiest Effects rules.

Project 4 — Quiz app (Redux Toolkit + TanStack Query)

Definition

A timed quiz whose questions come from an API via TanStack Query, while the in-progress attempt — current question index, chosen answers, and score draft — lives in Redux Toolkit, proving the course ownership rule.

In simpler words

Questions are server data (Query). Your unfinished attempt is client state (RTK). Never store the question list in Redux.

RTK deliverables (required): configureStore; a quizSlice with currentIndex, answers keyed by questionId, and status/score draft; typed useAppDispatch / useAppSelector; Provider on the client tree.

Query deliverables: useQuery to load questions (Open Trivia DB or a Nest/stub); optional useMutation to submit a result with invalidateQueries; disable submit while pending.

Auth (only if you use your own backend): Axios withCredentials; 401 → prompt login; no JWT in localStorage.

Polish: honest loading/empty/error; a results screen derived from RTK answers + Query questions, not a third stored copy.

Topics covered: RTK store/slice/hooks, client vs server ownership, TanStack Query, Axios/cookies, deriving UI from two sources.

Acceptance checklist — Project 4

- [ ] configureStore + quizSlice + typed hooks committed
- [ ] Questions live only in Query (never copied into Redux)
- [ ] Selected answers + current index live in RTK
- [ ] Score is derived from RTK answers, not stored twice
- [ ] Loading/empty/error are distinct; submit disabled while pending
- [ ] No JWT in localStorage

If the question list is also in Redux, this project fails the ownership bar.

Slice shape (sketch)

const quizSlice = createSlice({
  name: 'quiz',
  initialState: { currentIndex: 0, answers: {} as Record<string, string> },
  reducers: {
    answer(state, action: PayloadAction<{ id: string; choice: string }>) {
      state.answers[action.payload.id] = action.payload.choice;
    },
    next(state) { state.currentIndex += 1; },
    reset() { return { currentIndex: 0, answers: {} }; },
  },
});

Keep the attempt client-owned. Do not store the fetched questions[] here.

Project 5 — Weather app (Next.js App Router)

Definition

A weather lookup app hosted in the Next.js App Router, with a Server Component page shell composing a Client Component search leaf, next/link navigation, route metadata, and TanStack Query fetching a public weather API from the client subtree.

In simpler words

Build the shell on the server; keep the interactive search on the client. Data still comes through Query.

Deliverables: an app route (e.g. /weather); a Server Component page composing a client <WeatherSearch>; AppProviders (QueryClientProvider, plus a Redux Provider if you carry a search draft) wrapping only the client subtree; next/link nav; loading/error UI; page metadata; city search or geolocation.

Data: use a free API such as Open-Meteo (no key required) via Query; include the resolved location in the query key.

Topics covered: Next layouts/pages, Link, Server vs Client Components, Provider placement, metadata, fetching with Query inside a Client Component.

Acceptance checklist — Project 5

- [ ] use client only on the interactive leaf + providers module
- [ ] QueryClientProvider is not on a Server Component file
- [ ] Internal navigation uses next/link
- [ ] Query key includes the searched location; empty ≠ loading ≠ error
- [ ] Page sets metadata (title/description)

Moving into Next must not turn the whole route into a client component for one input.

Project 6 — GitHub repo explorer (RTK chrome + Query filters)

Definition

A GitHub repository explorer where filter inputs (query text, language, sort) are held as a filterDraft in Redux Toolkit and copied to appliedFilters only on submit, while TanStack Query owns the results using the applied filters and page in its query key.

In simpler words

Typing in filters updates RTK only. Pressing Search commits the filters and Query refetches — no request spam on every keystroke.

RTK deliverables: a filtersSlice with filterDraft (q/language/sort), appliedFilters (committed on submit), and UI chrome flags (e.g. isDetailsOpen); actions applyFilters / resetFilters / toggleDetails.

Query deliverables: queryKey includes appliedFilters + page; results refetch when applied filters change — not on every keystroke; pagination via the GitHub Search API.

Proof: an ARCHITECTURE.md ownership table (React / RTK / Query / Next / API) with one sentence each, and a demo script: type filters → apply → paginate → open a repo.

Topics covered: RTK for shared client UI chrome, Query keys and pagination, the revision map, the Query-vs-RTK challenge, failure honesty.

Acceptance checklist — Project 6

- [ ] Typing in filters updates RTK filterDraft only (Network tab shows no request per keystroke)
- [ ] Submit copies filterDraft → appliedFilters and the Query key changes
- [ ] Repo results live only in Query; never mirrored into Redux
- [ ] Pagination is part of the query key; empty/loading/error are distinct
- [ ] ARCHITECTURE.md names RTK for chrome/drafts and Query for API data

RTK handles chrome and drafts; Query handles reads. This is the whole course thesis on one screen.

Ownership cheat sheet

RTK:   filterDraft, appliedFilters, selected id, UI flags
Query: repo results + pagination (GitHub API)
Next:  routes, RSC shell, metadata
API:   the external service is the source of truth

If a value could change on the server for another user, it does not belong in RTK.

Suggested order and coverage map

Definition

A coverage map lists which curriculum concepts each project exercises, so the set as a whole leaves no major frontend skill untested.

In simpler words

Do them in order; together they cover the entire frontend track.

Order: P1 portfolio → P2 flash cards → P3 pomodoro → P4 quiz → P5 weather (Next) → P6 GitHub explorer.

Coverage: HTML/CSS/responsive/accessibility (P1); React fundamentals (P2); Effects/refs/custom hooks (P3); RTK + Query + cookies (P4); Next App Router + Server/Client (P5); RTK chrome + Query filters + architecture (P6).

Rough timebox: P1 0.5 day, P2 0.5 day, P3 0.5–1 day, P4 1–1.5 days, P5 1 day, P6 1 day.

Want more? Pick any idea from the roadmap.sh React/Next project lists (Roadmaps / Project Ideas in the navbar) once these are done.

Keep in mind

P1–P2 need no store. P3 is Effects and refs. P4+ use RTK for client state and Query for server/API data.
Prove behaviour with Redux DevTools and the Network tab, not only the happy-path UI.
Use free public APIs (Open-Meteo, Open Trivia DB, GitHub) so you can build without your own backend.
Each project ships a short README: how to run it and which topics it covers.
When stuck, reopen the matching week’s topics before adding another library.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. Project 1 (portfolio): which approach fits a responsive landing page?

Concept

Absolutely position every section and hard-code pixel widths for one screenSemantic landmarks with a Flexbox nav and CSS Grid cards, plus a mobile breakpoint with no horizontal scrollSkip alt text and focus styles because it is only practiceReach for a component library before the box model works

2. Project 2 (flash cards): this list misbehaves after you delete a card. What is the fix?

Syntaxintermediate

{cards.map((card, i) => (
  <Card key={i} card={card} onDelete={() => remove(i)} />
))}

Use a stable card.id as the key instead of the array indexWrap the map in useMemo so the index keys stay stableCall remove(i) during render to prune the array firstAdd a second key with Math.random() to force freshness

3. Project 3 (pomodoro): the countdown freezes at one value. Which change fixes this interval?

Practicalintermediate

useEffect(() => {
  const id = setInterval(() => setSeconds(seconds - 1), 1000);
  return () => clearInterval(id);
}, []);

Use the functional updater setSeconds(s => s - 1) so each tick reads the latest valueAdd seconds to the dependency array while keeping setSeconds(seconds - 1)Remove the cleanup so the original interval keeps runningMove seconds into a ref and mutate it directly each tick

4. Project 4 (quiz): which line breaks the RTK-vs-Query ownership rule?

Logicadvanced

const { data: questions } = useQuery({ queryKey: ['quiz'], queryFn: fetchQuiz });
useEffect(() => {
  if (questions) dispatch(quiz.setQuestions(questions));
}, [questions]);

useQuery should be replaced by useEffect plus fetch for questionsThe effect dependency array should be emptydispatch(setQuestions(questions)) copies server data into Redux — keep questions only in Queryquestions must be read via useAppSelector after dispatch

5. Project 4 (quiz): what is required to introduce a real Redux Toolkit store?

Concept

A single mutable global object imported where neededOnly useState lifted to the top componentReact Context holding the fetched questions arrayconfigureStore, a createSlice, typed useAppDispatch/useAppSelector, and a Provider on the client tree

6. Project 5 (weather): how do you keep the page mostly server-rendered?

Practical

Keep the page a Server Component and mark only the interactive search leaf use clientAdd use client to the whole route for one search inputFetch on the server and drop client interactivity entirelyUse next/link as the interactivity boundary

7. Project 5 (weather): where does QueryClientProvider belong in the App Router?

Syntax

At the root Server Component so the whole tree becomes clientInside each leaf component that calls useQueryIn a client providers module wrapping only the interactive subtree, never a Server Component fileIn a Route Handler under app/api

8. Project 6 (GitHub explorer): how do you avoid spamming the API while typing filters?

Logic

Put the raw input straight into the Query key on every keystrokeKeep filterDraft in RTK while typing and put only appliedFilters (committed on submit) plus page in the Query keyDebounce by storing results in Redux between fetchesRefetch in an Effect on each character and cache in a ref

9. Project 6 (GitHub explorer): which ARCHITECTURE.md ownership split is correct?

Concept

RTK for drafts/UI chrome, Query for API data, Next for routes, the external API as source of truthRedux owns all remote GET data and paginationNext owns the product data rulesThe component tree holds the server list in useState

10. Across these projects, which rule holds from Project 4 onward?

Practical

Any shared value should live in Redux for convenienceRedux Toolkit owns client-only state while TanStack Query owns server/API data — never bothServer data belongs in Redux once it is fetchedClient drafts belong in the Query cache

11. Project 1: what is the accessibility problem here?

Conceptintermediate

<div class="nav">
  <div onclick="go()">Home</div>
</div>

Use semantic <nav> and real <a>/<button> elements instead of clickable divsAdd role="navigation" to the div and keep the clickable divsGive each clickable div a tabindex so it’s accessible enoughAttach onKeyDown to the divs instead of using anchors

12. Project 3: what does listing seconds in the deps cause?

Syntaxadvanced

useEffect(() => {
  const id = setInterval(() => setSeconds(s => s - 1), 1000);
  return () => clearInterval(id);
}, [seconds]);

It leaks a new interval every second without clearing the oldIt freezes the countdown after the first tickIt makes the timer decrement two seconds per tickThe interval is torn down and recreated every tick — drop the dep and rely on the updater

13. Project 2: what does this toggle demonstrate?

Practicalintermediate

const [flipped, setFlipped] = useState(false);
<button onClick={() => setFlipped(!flipped)}>Flip</button>

A controlled input bound to a checkboxA ref-based flip that skips the re-renderBoolean state toggling to flip the cardA value derived during render, not stored in state

14. Project 6: why does this spam the API?

Logicadvanced

const [draft, setDraft] = useState('');
useQuery({ queryKey: ['repos', draft], queryFn });

The raw input is in the query key, refetching on every keystroke; key on applied filters insteadThe queryFn runs only once regardless of draftuseQuery ignores key changes after the first mountThe draft must be memoized or the query throws

15. Project 5: what is wrong with this provider placement?

Conceptintermediate

// app/layout.tsx (Server Component)
<QueryClientProvider client={qc}>{children}</QueryClientProvider>

Move it into generateMetadata so it runs server-sideWrap each useQuery call in its own provider insteadQueryClientProvider is client-only; put it in a "use client" providers module, not a Server ComponentPass the QueryClient as a prop from the layout

Checking your session…