How to learn React
This path assumes you know JavaScript and the DOM, and that you want to understand why React re-renders before you memorise hook names. It takes 70-90 hours and ends with you able to diagnose performance problems and design component boundaries without guessing.
Hours
70-90 hours
Calendar
about 12-15 weeks at 6 hours a week
Stages
7
Start from
You need working knowledge of JavaScript: closures, array methods, event handling, and how the DOM updates. If you have never written a plain JavaScript event listener, start there. You do not need TypeScript, build tools, or any framework experience.
Why the usual order fails
Most React tutorials start with components and JSX, then add state, then props, then hooks as a later chapter. That order teaches you to write code that looks like React but breaks the moment a parent re-renders or a state update happens twice. You learn the syntax before you learn the runtime, so every bug becomes a mystery about invisible machinery. The result is developers who can build a to-do list but cannot explain why their form loses focus on every keystroke, or why memoising one component made the app slower.
This path starts with the render cycle: what happens when React calls your function, how it compares the result with the previous tree, and what it actually writes to the DOM. In week one you build a counter with no useState, using a manual render function, so you see what the hook hides. Only then do you add state, effects, and the rest. When a hook appears, you already know the problem it solves, because you have felt that problem in code you wrote yourself.
The path, in the order it has to be walked.
Each stage assumes the one above it and nothing below it. The check at the foot of each is the point — you are meant to fail it, go back, and try again before moving on.
The render cycle, without hooks
weeks 1-2Build components as plain functions and call them manually. Watch what happens when you call the same function twice, pass different props, and replace the DOM node. This stage makes reconciliation visible before any abstraction hides it.
- JSX compilation to createElement
- Function components as pure functions
- The virtual DOM and element diffing
- Keys and why index keys break lists
- Manual render functions and root.render
- StrictMode double-invocation
- Reconciliation of children arrays
You can now: Take a component with three children and rewrite it so that reordering the children does not remount them, using keys you chose deliberately.
State and the update queue
weeks 3-4Introduce useState and see what it automates: scheduling, batching, and triggering re-renders. Now the manual render loop becomes the hook's job, and you can explain exactly what changed.
- useState and the state setter queue
- Batching across event handlers
- State immutability and object identity
- Lazy initialisers
- Derived state vs duplicated state
- Updater functions for sequential updates
- Why state lives in the parent
You can now: Build a form with three fields where typing in one field does not cause the other two to lose focus, and explain why the naive version does.
Effects as synchronisation
weeks 5-6Learn useEffect last among the core hooks, because it is the escape hatch, not the default. Understand what it synchronises with and what happens when you get the dependency array wrong.
- useEffect and the dependency array
- Cleanup functions and why they run
- Infinite loops from missing or object deps
- useLayoutEffect and when it matters
- Fetching data without race conditions
- AbortController and stale closures
- Effects vs event handlers
You can now: Write a subscription component that connects, disconnects, and reconnects correctly when a prop changes, with no duplicate connections at any point.
Context and composition
weeks 7-8Pass data down without prop drilling, and learn when context is the wrong tool. Composition — passing JSX as children — solves most of the problems people reach for context to fix.
- createContext and useContext
- Provider value identity and re-renders
- Context vs prop drilling vs composition
- Compound components
- Render props
- Higher-order components and their cost
- Splitting contexts to limit re-renders
You can now: Refactor a component with five levels of prop drilling so that adding a new intermediate component does not require touching any existing component's props.
Performance and memoisation
weeks 9-10Learn to measure before you memoise. React.memo, useMemo, and useCallback are tools with costs; this stage teaches you when they pay for themselves and when they make things worse.
- React DevTools Profiler
- React.memo and shallow comparison
- useMemo for expensive calculations
- useCallback and stable references
- Why memoising everything slows you down
- Component boundaries and re-render scope
- The useDeferredValue escape hatch
You can now: Take an app with a slow list and a fast input, profile it, and make the input stay responsive while the list filters, naming the specific component that re-renders before and after.
Data fetching and server state
weeks 11-12Move beyond useEffect for data. Learn what a proper data layer looks like: caching, invalidation, and optimistic updates. This stage uses React Query or similar, because hand-rolling this is a known failure mode.
- Why useEffect fetching fails at scale
- React Query: useQuery and useMutation
- Cache keys and stale time
- Invalidation after mutations
- Optimistic updates and rollback
- Parallel and dependent queries
- Prefetching and pagination
You can now: Build a list with create, update, and delete operations where the UI updates immediately, rolls back on server error, and refetches only the changed item.
Routing and app structure
weeks 13-14Add navigation and think about where state lives across routes. This stage is last because routing decisions depend on component boundaries and data patterns you have already built.
- React Router: createBrowserRouter
- Nested routes and layouts
- Loaders and actions vs useEffect
- URL as state
- Protected routes and redirects
- Code splitting with lazy and Suspense
- Error boundaries and fallback UI
You can now: Build a two-page app with a shared layout, a protected route, and a detail page that loads data based on the URL without a loading spinner flash on back navigation.
The hours are fixed. The calendar is yours.
The same path at three speeds, and what actually goes wrong at each.
3 hours a week
This pace takes about 24-30 weeks. The main risk is context loss between sessions: the render cycle stage needs contiguous thinking time, and a week between sessions means re-learning the previous session's mental model before you can build on it.
8 hours a week
This pace takes about 9-11 weeks. It is sustainable if you split into two or three sessions. The data fetching and performance stages benefit from longer blocks, because profiling and debugging require holding the call stack in your head.
20 hours a week
This pace takes about 4-5 weeks. It works for an intensive period, but the later stages suffer: you need time for the mental model to settle, and cramming reconciliation and effects into the same week produces confusion that looks like competence until you hit a real bug.
Four ways people lose a year on this.
Each of these is appealing for a real reason, which is why they are common. What they cost is the part nobody mentions.
Learning hooks before the render cycle
Most tutorials introduce useState in lesson one, so you never see what it automates. You can write working components but cannot explain why a parent re-render causes a child to re-render, or why a state update inside a loop behaves unexpectedly. When a bug appears, you guess instead of reasoning.
Using useEffect for everything
Because useEffect is the first hook people learn for side effects, it becomes the default for derived data, event handling, and data fetching. This leads to double-fetching, infinite loops, and race conditions. The fix is usually to compute during render or move logic to an event handler, but that only makes sense once you understand the render cycle.
Memoising without measuring
React.memo, useMemo, and useCallback look like free performance wins, so developers wrap everything. Each memoisation adds comparison cost and code complexity, and often prevents re-renders that were cheap anyway. The result is slower apps and code that is harder to change, all for a problem that may not have existed.
Putting all state in one context
A single context with a large object value re-renders every consumer when any field changes. This is appealing because it mirrors a global store and avoids prop drilling, but it turns a small update into a full app re-render. Splitting contexts or using composition fixes it, but only if you know how context value identity works.
How to know it worked.
Not a syllabus you tick off — six things to attempt. If one of them is still hard, the stage it belongs to is the one to go back to.
- Write a component that re-renders and explain what triggers it.
- Build a list with keys and show why index keys break on reorder.
- Create a counter with useState and predict each render's output.
- Write an effect that cleans up correctly on every dependency change.
- Memoise a component and prove it prevents a child re-render.
- Build a form that keeps focus in every field while typing.
Questions about learning React.
The five we hear most. The intro film answers most of them in a minute and a half.
how long does it take to learn react
If you already know JavaScript and the DOM, expect 70-90 hours of focused work to reach genuine working competence. That means building projects, hitting bugs, and understanding why they happened, not just watching tutorials. At 6 hours a week that is 12-15 weeks.
do i need to learn typescript before react
No. TypeScript adds type checking on top of JavaScript, and React's core model — components, state, effects, reconciliation — is the same with or without it. Learn React in plain JavaScript first, because TypeScript errors will otherwise distract you from understanding what React itself is doing.
is react still worth learning in 2025
Yes, but the reason has changed. React is no longer the only sensible choice for new projects, but it remains the most widely used UI library in job listings and existing codebases. The rendering model it teaches — components, state, reconciliation — transfers to other frameworks, so the time is not wasted even if you later switch.
should i learn next js at the same time as react
No. Next.js adds routing, server rendering, and build configuration on top of React. If you learn both at once, you cannot tell which behaviour comes from React and which from Next.js, and every bug becomes harder to trace. Get comfortable with client-side React first, then add Next.js as a separate layer.
do i need to know redux to get a react job
No. Most React jobs today use server state libraries like React Query or built-in context, not Redux. Redux is still used in older codebases, but it is a specific tool for a specific problem. Learn the rendering model and state management fundamentals first, and pick up Redux only if a job requires it.
A path is not a course.
This is the shape of React, not the teaching of it. Hand the same path to BiliMind and it writes the lessons onto it — in the form each one calls for, with practice that gets marked and a schedule that bends when your week does. Mapping a course is free and unlimited.
This roadmap was drafted on 18 September 2026 by the same engine that builds BiliMind courses, and reviewed before publishing. Hours are honest estimates for working competence, not for a demo — treat them as a starting point and adjust them against your own first fortnight.