Junior React Onboarding Handbook

How long do you usually spend “getting oriented” before you can actually change something in a React repo? If you can’t answer that, you’ll probably lose hours to the same loop: search for a component, miss the right one, then guess where state or routing lives. This chapter teaches you a fast way to build a codebase map that matches how the app really works, so your next change lands in the right place.

You’ll learn where features live, how routing and state connect to the UI, what conventions your team uses, and how to trace a user journey from a button click to the code that runs. After this chapter, you should be able to open a repo, identify the main routes, find the feature folder for a screen, locate the state source for what the user sees, and follow the call chain to the API or data layer-without relying on luck.

Why This Matters

In an existing React repository, the hardest part usually isn’t writing React-it’s finding the right entry points. Teams often split “screen UI,” “feature logic,” “data fetching,” and “shared components” across different folders. If you don’t know the shape, you’ll keep opening the wrong files, then you’ll start adding code in the wrong place and fight the team’s patterns.

This chapter solves a specific problem: you need a repeatable way to orient yourself in under an hour. Instead of reading the whole repo (no one does that), you’ll build a map using the routing table and the state flow you can actually see. Then you’ll trace a single user journey end-to-end: from the visible UI element, to the route or page, to the state that drives it, to the actions that update it.

By the end, you’ll be able to answer questions like: “Which folder owns the Checkout screen?”, “Where does the app read the current user?”, and “When I click ‘Save’, where does the request get sent?”. Ask yourself as you read: if you had to implement one small change today, could you point to the exact files that should change?

Practical takeaway: Orientation turns “search time” into “trace time.” Your goal is to trace one journey accurately, not to memorize the whole repo.

How It Works

The core technique you’ll use is the Feature Trace Compass. It helps you move through the repo in the same order the app behaves: route → page → feature → state → side effects (like API calls). You’re not hunting randomly; you’re following a path with checkpoints you can verify.

Start with the route entry points, because routing tells you where screens attach to URLs. Then find the page component for that route, and from there find the feature module that owns the behavior. Once you locate the feature, you can identify where the state comes from (local component state, shared state store, or data returned from hooks). Finally, you trace the “side effects” that happen on user actions: dispatching actions, calling mutation hooks, or hitting an API wrapper.

Use these steps as your compass:

1. Find the router entry file

• Look for where the app mounts `` or similar route declarations (common names: `router.tsx`, `routes.tsx`, `AppRoutes.tsx`).
• Confirm the “base” by checking which file renders the top-level router component.
• Why this matters: if you start from a random component tree, you’ll miss the real screens and URL mapping.

2. List the route → page mapping

• For the screen you care about (start with the easiest one), find the route path (example: `/settings` or `/users/:id`).
• Identify the component used for that route (example: `SettingsPage`).
• Why this matters: the route component name tells you what folder owns the screen, and it gives you a stable anchor.

3. Jump from the page to the feature module

• Open the page component and look for imports that come from a feature folder (common patterns: `features/settings/`, `modules/billing/`, `domain/checkout/`).
• Identify the “main” feature component or hook used by the page.
• Why this matters: pages often stay thin; features hold the real logic and state wiring.

4. Trace state ownership from the feature

• Find where the feature reads state (props, a custom hook, a store hook like `useXStore`, or data returned from a query hook).
• Then find where user actions trigger updates (a handler that calls a mutation hook, dispatches an action, or calls an API function).
• Why this matters: the UI usually doesn’t “store” data itself-state ownership tells you the correct place to change behavior.

A concrete mini-example (with numbers you can spot)

Say you need to understand what happens when a user clicks “Save profile” on a Settings screen.

• You find the route for `/settings` and see it renders `SettingsPage`.
• In `SettingsPage`, you see it imports `ProfileSettings` from a feature folder like `features/settings/profile/ProfileSettings`.
• Inside `ProfileSettings`, you find a handler called `handleSave` (or a button onClick that calls something)....