Back to learning
React

Build a personal task manager

Build a task manager end to end: render it, give it a single source of truth, then put it on a real API.

  • Beginner
  • About 5 weeks
  • 3 milestones
  • 6 steps
  • Every step reviewed
TypeScriptReact
Start this journey
What you will have builtA working task manager whose state has one owner and whose network failures are visible rather than silent.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 5 weeksAn estimate, not a deadline
3 milestonesEach one claims a capability
6 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.

React basicsRender a list from data and change what appears without touching the DOM yourselfEverything later is easier once the screen is a function of data rather than a sequence of edits.
2 steps
Show the 2 steps
  • Render the task list from dataReviewed

    Show the tasks that exist in an array, with nothing hard-coded in the markup.

  • Add and complete a taskReviewed

    Let the learner add a task and complete one, entirely through state.

State managementGive the application one source of truth that any component can read without prop chainsThe moment a second screen needs the same tasks, local state stops being an answer.
2 steps
Show the 2 steps
  • Move the tasks into a storeReviewed

    Hold the task list outside the component tree and read it where it is needed.

  • Name every change to the stateReviewed

    Express each change as a named operation instead of a raw setter.

API integrationPut the task manager on a real API without the interface flickering, lying or crashingState first, then the network — the failure modes only make sense once state has one owner.
2 steps
Show the 2 steps
  • Load the tasks from the APIReviewed

    Replace the seeded array with a real request, including its loading and empty states.

  • Survive a failing requestReviewed

    Make a failed save visible and recoverable rather than silent.

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 task manager whose state has one owner and whose network failures are visible rather than silent.Built by you, in your own repository.
6 pieces of work, each read by an engineerEvery round and every comment stays on the record, including what changed between them.
3 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 Build a personal task manager?

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