Back to learning
React

React: state and real data

Build an interface that holds its own state and survives a slow, failing network.

  • Beginner
  • About 4 weeks
  • 2 milestones
  • 4 steps
  • Every step reviewed
TypeScriptReact
Start this journey
What you will have builtA working React application whose state is deliberate and whose loading and error paths are real.Start this journey

What this asks of you

Every figure below is read from the journey itself, not written about it.

BeginnerNo prior experience needed
About 4 weeksAn estimate, not a deadline
2 milestonesEach one claims a capability
4 stepsShort, and every one is built
Every step reviewedAn engineer reads all of it, when mentor guided

What you will be able to do

Every milestone claims one engineering capability. You reach it by building something, not by finishing a chapter.

StateHold UI state in one place and read it from any component that needs itEverything after this depends on knowing where a value lives and who may change it.
2 steps
Show the 2 steps
  • Move the counter into a storeReviewed

    Replace a component-local counter with state held outside the component.

  • Make the update logic explicitReviewed

    Express every change to the counter as a named operation rather than a raw setter.

EffectsLoad data from an API without the interface flickering, lying or crashingState first, then the network — the failure modes only make sense once state is settled.
2 steps
Show the 2 steps
  • Load the list on mountReviewed

    Fetch the list from the API and render it, including while it is loading.

  • Survive a slow networkReviewed

    Ensure a request that resolves late cannot write to a view that has moved on.

How the work is verified

  1. ReadThe context you need for this step, and why it matters. Never more than that.
  2. BuildYou produce something real. The work is yours, in your own repository.
  3. SubmitYou send it, with a note on what you chose and what you were unsure about.
  4. ReviewA senior engineer reads it and responds. They may ask for changes — that is the normal path through engineering review, not a failure.
  5. VerifiedThe capability is confirmed, it goes on your record, and the next step opens.

How you want to work

You choose when you start. Both cover the same journey and the same definition of done.

Mentor guidedReviewed by a person

A senior engineer is assigned to you. They read every submission, respond in writing, and decide when a capability is verified. Expect to be asked for changes.

Self pacedVerified by you

You work through the same journey and verify your own work against the same definition of done. Nothing is submitted to anyone, and nothing waits on anyone.

What you end up with

Counted from this journey, not described in general.

A working React application whose state is deliberate and whose loading and error paths are real.Built by you, in your own repository.
4 pieces of work, each read by an engineerEvery round and every comment stays on the record, including what changed between them.
2 verified capabilitiesEach one confirmed against its definition of done, with the name of whoever confirmed it. There is no certificate. The work is the credential.

Ready to start React: state and real data?

You will choose how you want to work on the next screen. Nothing starts until you confirm it. You can run several journeys at once, and each one is mentor-guided or self-paced on its own.

Start this journey