Skip to main content

3. Routing, Permissions & State

Goal for this page: be able to answer "how does a user get to this screen, and where does its data live?" for any feature in the app.

Step 3.1 — Routing​

What & why: Routing maps URLs to feature screens. Because features live in separate libraries, the routing setup is how they're stitched into an app.

Learn:

Your task: Pick one screen in the running app. Find its route in the code, then trace which component/library that route renders. Confirm it matches the Routes doc.

Step 3.2 — Permissions​

What & why: Not every user sees every feature. Access is gated by a permissions system, so what renders depends on the logged-in user's permissions — you must account for this whenever you add or change a screen.

Learn:

Your task: Take the route you traced in Step 3.1 and find what permission (if any) guards it. Describe what a user without that permission would see.

Step 3.3 — State management​

What & why: The app manages state with the React Context API in a two-level structure:

  • Global state — a single app-wide AppStore (login data, selected category, sidebar state, global date filter, etc.), located around libs/shared/src/store/.
  • Feature state — each feature library keeps its own store under libs/{feature}/src/store/.

Knowing which level a piece of state belongs to is a core design decision you'll make often.

Learn:

Your task:

  1. Open the global AppStore in libs/shared and list three pieces of state it manages and the methods that update them.
  2. Pick one feature library and find its own store — note one piece of state that is correctly kept local to that feature rather than global. Why does it belong there and not in AppStore?
Checkpoint

You can trace a route to its component, know how permissions gate it, and know where its state lives. Next: the shared UI and how the app talks to the backend.

Next: → Components & API layer