My progress
Menu

Level 4 · Full-Stack Application Development · Course 4.2 Frontend Architecture

Module 40: Dashboard Project

Goal: plan and build a complete, professional dashboard frontend: requirements, layouts, data tables with filters, API integration, tests and a review. It becomes the frontend of your Level 4 project.

You'll need: everything from Modules 31 to 39.

Lessons

  1. 1Requirements for a dashboard15–25 minutes✓
  2. 2Layouts for dashboards15–25 minutes✓
  3. 3Tables, filters and sorting15–25 minutes✓
  4. 4Integrating the API15–25 minutes✓
  5. 5Testing and review15–25 minutes✓

🛠️Module practice: Course 4.2 project, a dashboard frontend

  1. Requirements, sketches and an endpoint list.
  2. A responsive app shell with summary cards.
  3. An accessible, sortable, filterable, paginated table, with settings in the URL and cards on phones.
  4. Detail page with status, assignment and notes; create form; delete for admins only (in the UI).
  5. Tests, quality checklist, review, README. Commit and merge the pull request.

✅Module check

Explain in a few sentences, in your own words:

How would you plan and build a dashboard that people can rely on every day?

Show a good answer

A good answer mentions: start from who uses it and what decisions they make; write precise, testable requirements and an endpoint list; sketch screens. Build a responsive layout that puts what needs action first; use accessible tables with sorting, filtering and pagination (server-side for large data) kept in the URL; connect through a typed API client with caching and clear states. Test components and requirements, check accessibility, phones, slow networks and edge cases, review the code critically, and document limits.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. Why define "overdue" precisely?

Why each option is right or wrong

  • “So the dashboard loads more quickly” (Incorrect): A precise definition doesn't change speed; it removes confusion.
  • “Because TypeScript rejects vague words in variable names” (Incorrect): TypeScript doesn't check meaning; people and tests do.
  • “So it can be changed freely without telling anyone” (Incorrect): The point is shared agreement; changes should be agreed too.
  • “So code, tests and people all mean the same thing” is correct.

    "Overdue" could mean older than a day, older than two working days, or past a promised date. Writing an exact rule, like "status is new and created more than 48 hours ago", means the code, the tests and the team agree on which enquiries count.

    • Vague words to pin down: overdue, recent, active, urgent.
    • Write it once: in the requirements, then in one function.

📖 Revise: Lesson 1: Requirements for a dashboard

Question ID module-40-q1 · Report a mistake in this question
2. Why list API endpoints before building the frontend?

Why each option is right or wrong

  • “Browsers need the full list of endpoints before they can make any requests” (Incorrect): Browsers don't need it; people and code need the agreement.
  • “It's required to get a domain name for the site” (Incorrect): Domains have nothing to do with endpoint lists.
  • “So the frontend can skip handling errors” (Incorrect): Errors still happen; the contract should list them.
  • “They form the contract both sides build and test against” is correct.

    Writing down each endpoint, what it accepts and what it returns lets the frontend and backend be built at the same time, against a pretend API if needed. When they meet, they fit, because both followed the same contract.

    • Include: method, path, inputs, response shape and errors.
    • Example: GET /enquiries?status=new&page=1.

📖 Revise: Lesson 1: Requirements for a dashboard

Question ID module-40-q2 · Report a mistake in this question
3. What should be most prominent on an enquiry dashboard?

Why each option is right or wrong

  • “A large welcome message with the person's name and today's date” (Incorrect): A friendly touch, but it doesn't help anyone decide what to do next.
  • “A chart of every enquiry since the business began” (Incorrect): Long history is less useful than what needs action today.
  • “The full text of the newest enquiry” (Incorrect): One enquiry's text hides the overall picture.
  • “What needs action: counts of new and overdue enquiries” is correct.

    A dashboard is for deciding what to do next. Putting "5 new, 2 overdue" at the top shows immediately where attention is needed, with less urgent details below.

    • Ask: what will the person do after looking at this?
    • Less prominent: totals and history.

📖 Revise: Lesson 2: Layouts for dashboards

Question ID module-40-q3 · Report a mistake in this question
4. Why should a summary card link to a filtered table?

Why each option is right or wrong

  • “Summary cards can't display their numbers unless they are links” (Incorrect): Cards can show numbers either way; the link adds a useful next step.
  • “Links make the numbers update faster” (Incorrect): Links don't affect how often numbers update.
  • “Search engines need links on every card” (Incorrect): This is for the person using the dashboard, not search engines.
  • “People can go straight from a number to the items behind it” is correct.

    Seeing "2 overdue" naturally leads to "which ones?". Making the card a link to the table filtered to overdue enquiries removes the step of finding and setting the filter by hand.

    • Use the address: /enquiries?status=overdue.
    • Accessible: make the card a real link with a clear name.

📖 Revise: Lesson 2: Layouts for dashboards

Question ID module-40-q4 · Report a mistake in this question
5. With 50,000 enquiries, where should filtering and sorting happen?

Why each option is right or wrong

  • “In the browser, after downloading all 50,000 rows when the page opens” (Incorrect): That's a slow download and heavy work for the browser.
  • “In the browser, but only on fast computers” (Incorrect): Even on fast computers, downloading everything is wasteful.
  • “Nowhere; show all 50,000 rows at once” (Incorrect): No one can use a 50,000-row table, and it would be very slow.
  • “On the server, which sends only the requested page” is correct.

    Sending 50,000 rows to the browser is slow to download and heavy to filter. The database can filter, sort and return just 25 rows for the current page quickly.

    • API: GET /enquiries?status=new&sort=created&page=2.
    • Small lists: filtering in the browser is fine.

📖 Revise: Lesson 3: Tables, filters and sorting

Question ID module-40-q5 · Report a mistake in this question
6. Why include the filters in the query key?

Why each option is right or wrong

  • “TanStack Query requires every query key to have at least two parts” (Incorrect): Keys can have one part or many; filters are included so they're tracked.
  • “It hides the filters from the server” (Incorrect): The filters are still sent to the server; the key is for the cache.
  • “It saves the filters permanently in the database” (Incorrect): The key lives in the browser's cache, not in a database.
  • “Each combination is cached separately and fetches the right data” is correct.

    If the key is just ["enquiries"], changing a filter doesn't change the key, so the old results stay on screen. With ["enquiries", filters], each combination gets its own cache entry and a fetch when it changes.

    • Bonus: switching back to an earlier filter shows its cached results straight away.
    • Same for: page number and sort order.

📖 Revise: Lesson 4: Integrating the API

Question ID module-40-q6 · Report a mistake in this question
7. An AI review suggests 15 changes. Do you make them all?

Why each option is right or wrong

  • “Yes, AI reviews are more accurate than human ones” (Incorrect): AI reviews can be wrong; your judgement decides.
  • “No, ignore AI reviews completely” (Incorrect): Some suggestions will be useful; ignoring them all wastes good catches.
  • “Yes, but only if all 15 are short changes” (Incorrect): Size doesn't decide it; whether each is correct does.
  • “No, judge each: fix what's right and explain the rest” is correct.

    AI reviews mix good catches with suggestions that are wrong, unnecessary or against your requirements. Consider each: fix real problems, and note why you're declining the others. That judgement is part of owning the code.

    • Prioritise: bugs and security first, style last.
    • Check it: test each change you accept.

📖 Revise: Lesson 5: Testing and review

Question ID module-40-q7 · Report a mistake in this question
8. Why record known issues in the README?

Why each option is right or wrong

  • “To make the project look more complete and finished than it really is” (Incorrect): It's about honesty, not appearances.
  • “Because GitHub won't publish a README without them” (Incorrect): GitHub publishes READMEs without such a list.
  • “So the issues fix themselves in the next version” (Incorrect): Writing issues down doesn't fix them; it informs people.
  • “So users and future developers know the limits in advance” is correct.

    Every project has limits, like "search only matches whole words". Writing them down saves people from discovering them the hard way and shows you understand your own project.

    • Honest: it builds trust with users and reviewers.
    • Useful later: a ready list of what to improve next.

📖 Revise: Lesson 5: Testing and review

Question ID module-40-q8 · Report a mistake in this question
9. Why use <th scope="col"> and aria-sort in a table?

Why each option is right or wrong

  • “They make the table columns sort automatically” (Incorrect): They describe the table; your code still does the sorting.
  • “They style the headers in bold” (Incorrect): Browsers often bold headers, but the attributes are for meaning, not style.
  • “They are needed for the table to appear on mobile” (Incorrect): Tables appear without them; they're for accessibility.
  • “Screen readers announce column names and the sort order” is correct.

    <th scope="col"> tells screen readers which header belongs to each column, so moving through cells announces "Status: new". aria-sort="ascending" on the sorted column says how the table is ordered.

    • Sort buttons: put a <button> inside the header so keyboards can use it.
    • Benefit: a table that's usable without seeing it.

📖 Revise: Lesson 3: Tables, filters and sorting

Question ID module-40-q9 · Report a mistake in this question
10. What does keepPreviousData do for a paginated table?

Why each option is right or wrong

  • “Saves every page permanently in the browser” (Incorrect): It only holds the last page briefly while the next one loads.
  • “Stops the table moving to the next page” (Incorrect): It still moves; it just avoids an empty flash.
  • “Downloads every page in advance” (Incorrect): That's prefetching, a different feature.
  • “Keeps the current page showing while the next loads” is correct.

    Without it, moving to page 2 gives a new query key with no data yet, so the table flashes to a spinner. Keeping the previous data shows page 1 until page 2 arrives, avoiding the jump.

    • Newer TanStack versions: placeholderData: keepPreviousData.
    • Show progress: a small indicator while the next page loads.

📖 Revise: Lesson 4: Integrating the API

Question ID module-40-q10 · Report a mistake in this question

ProLearners Assist