Connect Ticket APIs, Routing and Shared State

What you will build

Milestone 14: Separate URL navigation from ticket data retrieval. Use a replaceable mock adapter, a list route and a detail route. This checkpoint is for learning routing and network boundaries; it is not a production ticket system.

A real interface must display asynchronous data, separate ticket list and detail views, and recover from failures.

Visible checkpoint: The mock issue list loads after a short delay; users can navigate list/detail routes and retry errors. You can study this Byte by itself, though the project can also be built progressively.

Understand the concept first

Use React Router to map URLs to screens. Treat the server as the authoritative source once a backend exists. For this educational project use a replaceable mock adapter and simulate loading/error/retry. Do not claim the mock data is persisted centrally.

In plain language, an interface should show useful information and respond predictably to users. We begin with one small technical change before introducing more features.

Architecture: what happens underneath

Execution path

01Route → data adapter → loading → response/error → ticket screen

Follow the arrows and explain which step is React state, which is a browser action, and which would require a real backend.

Explore a realistic preview

Use the visual to predict what a user would see. The preview uses simulated demo data and does not represent a connected enterprise service.

Coding walkthrough step by step

Complete, ordered project checkpoints: Read the source-of-truth build guide. Use the full replacement files from that guide alongside the focused explanations below. Some snippets below demonstrate an insertion rather than a complete file.

Step 1 — Install routing

Edit or create the indicated file.

01npm install react-router

What this step accomplishes: A real interface must display asynchronous data, separate ticket list and detail views, and recover from failures.

Check: Run your app or inspect the updated component before continuing.

Step 2 — Create a mock data boundary

Edit or create the indicated file.

01// src/api/tickets.ts02import {initialTickets} from '../data/tickets';03export async function getTickets(){await new Promise(r=>setTimeout(r,350));return initialTickets;}

What this step accomplishes: The mock issue list loads after a short delay; users can navigate list/detail routes and retry errors.

Check: Run your app or inspect the updated component before continuing.

Step 3 — Add route components

Edit or create the indicated file.

01// src/main.tsx — wrap existing App in BrowserRouter02import {BrowserRouter} from 'react-router';03// <BrowserRouter><App /></BrowserRouter>04// src/App.tsx — when ready, use Routes and Route05import {Routes,Route,Link} from 'react-router';06// <nav><Link to="/tickets">Tickets</Link></nav>07// <Routes><Route path="/tickets" element={<TicketListPage/>}/>08// <Route path="/tickets/:id" element={<TicketDetailsPage/>}/></Routes>

What this step accomplishes: The mock issue list loads after a short delay; users can navigate list/detail routes and retry errors.

Check: Run your app or inspect the updated component before continuing.

Step 4 — Handle loading and errors

Edit or create the indicated file.

01// Use a loader effect in a client-only app or prefer a data-routing loader.02// Track: loading, error, data. Render clear retry UI.03// For cancellation, avoid committing responses from superseded requests.

What this step accomplishes: The mock issue list loads after a short delay; users can navigate list/detail routes and retry errors.

Check: Run your app or inspect the updated component before continuing.

Expected screen and execution

What you should observe: The mock issue list loads after a short delay; users can navigate list/detail routes and retry errors.

Trace it: Route → data adapter → loading → response/error → ticket screen. A user-visible output is stronger evidence than a code snippet alone.

Interactive decision and diagnosis

If the expected result does not appear, inspect the relevant file and resolve the first console error. Compare your current code to the preceding checkpoint.

Typical issue: Router page examples are insertion guides: create the referenced TicketListPage and TicketDetailsPage before use; do not paste undeclared names into App. Configure host fallback for direct URL refresh.

How teams use this pattern

A frontend developer implements the interface, a tester verifies accessible controls and failure behavior, and the product owner describes the expected result. This is a simplified demonstration of that collaboration, not a representation of a particular company's internal infrastructure.

Compare UI and implementation

Hands-on practice

Implement the two page components with a mock ticket lookup and an accessible error display.

Evidence: Capture the visible result, explain the code you changed, and reproduce one failure case.

Interview Bit

Question: How does this milestone change what the learner can actually do?

Answer: It demonstrates separate routes, mock data loading and error recovery without claiming a real backend.

Key Takeaways

1. BrowserRouter supplies browser-based navigation.
2. Routes connect URLs to list and detail pages.
3. Route parameters identify the selected ticket.
4. Mock adapters make remote-data boundaries explicit.
5. Loading should be announced while requests run.
6. Errors should include a meaningful retry option.
7. Prevent outdated requests from updating current screens.
8. A mock API is not a persistent multi-user backend.

Knowledge Check and Primary Sources

Frequently asked: Is a real backend required for this Byte? No; this handbook uses a mock boundary until you supply a real API. Does the demo contain real customer data? No.

Primary sources: React Router declarative setup · Effects and synchronization.