SaaS Dashboard

## 1. Learning Objectives By the end of this project, you will be able to design an authenticated SaaS dashboard with nested layouts, protected server data, Server Actions, loading states, and role-aware navigation. Difficulty: Advanced. ## 2. Prerequisites - Authentication. - Middleware or proxy concepts. - Server Components. - Server Actions. ## 3. Overview A SaaS dashboard is an app users return to every day. It needs dense navigation, reliable auth, fast data access, settings forms, analytics views, and clear loading/error states. ## 4. Why This Topic Matters Dashboards test whether you can build full product workflows, not just pages. They require careful data ownership, authorization checks, mutation handling, and layout composition. ## 5. Real-World Analogy A dashboard is a control room. The layout keeps the controls in the same place, while each screen shows a different part of the system. ## 6. Core Concepts | Concept | Role in a SaaS Dashboard | |---|---| | Route group | Separates app routes from marketing routes. | | Nested layout | Shared sidebar, header, and account switcher. | | Server auth check | Protects data close to where it is loaded. | | Server Action | Handles settings and mutations. | | Loading boundary | Shows skeletons while dashboard data loads. | ## 7. Syntax & API Reference

## 8. Visual Diagram

## 9. Live Example - Full Working Code

What just happened? The dashboard checks the session on the server before loading user-owned data, and settings updates go through a Server Action. ## 10. Interactive Playground Try this: - Add a dashboard route group. - Add sidebar navigation in a nested layout. - Add a settings form with a Server Action. - Add loading and error files for dashboard segments. ## 11. Common Mistakes | Mistake | Why It Happens | Correct Approach | |---|---|---| | Relying only on middleware | Route access feels protected. | Recheck authorization in server data paths. | | Making the entire dashboard client-side | Tables and forms need interaction. | Keep data pages server-first, isolate widgets. | | Missing loading states | Local data is fast. | Add `loading.tsx` for slower production data. | | Sharing data across tenants | Workspace filters are forgotten. | Scope every query by user and workspace. | ## 12. Best Practices - Use route groups to separate marketing and app surfaces. - Put persistent navigation in nested layouts. - Authorize close to data access. - Use Server Actions for form mutations. - Add loading, error, and empty states. ## 13. Browser Compatibility | Feature | Browser Impact | Notes | |---|---|---| | Server-rendered tables | Fast HTML | Good for dense dashboards. | | Client widgets | JavaScript required | Keep charts and controls isolated. | | Server Actions | Progressive form model | Add useful pending states. | ## 14. Interview Questions **Easy:** Why use a nested layout for a dashboard? Answer: It keeps navigation and shared chrome persistent across dashboard pages. **Medium:** Why recheck auth inside Server Components? Answer: Middleware can redirect, but data access still needs authoritative authorization at the server boundary. **Hard:** How would you design multi-tenant data access? Answer: Resolve the active workspace from the authenticated session, scope every query and mutation by workspace ID, and enforce role checks server-side. ## 15. Debugging Exercise Bug report: "Users can open another workspace by changing the URL." Solution The route likely trusts URL params without checking membership. Validate the authenticated user has access to the workspace before loading or mutating data. ## 16. Practice Exercises - Easy: Add a dashboard layout. - Medium: Add a protected overview page. - Hard: Add workspace-scoped settings with role checks and revalidation. ## 17. Scenario-Based Challenge A SaaS app has admins, members, billing owners, and multiple workspaces. Where should authorization live? Walkthrough Use middleware for coarse redirects, then enforce role and workspace checks inside Server Components, Server Actions, and Route Handlers before data access. ## 18. Quick Quiz 1. What file keeps dashboard chrome persistent? Answer: `layout.tsx`. 2. What handles form mutations? Answer: Server Actions. 3. Where should tenant checks happen? Answer: Server-side near data access. 4. What file handles pending route UI? Answer: `loading.tsx`. 5. Should dashboards ship all data to the client? Answer: No. ## 19. Summary & Key Takeaways - SaaS dashboards need layouts, auth, data ownership, and mutations. - Route groups help organize app and marketing areas. - Server-side authorization is mandatory. - Server Actions simplify settings forms. - Loading, error, and empty states make dashboards production-ready. ## 20. Cheat Sheet | Need | Pattern | |---|---| | App shell | Nested layout | | Public vs private routes | Route groups | | Protected data | Server auth check | | Settings update | Server Action | | Slow dashboard section | `loading.tsx` plus Suspense | ## 21. Further Reading - Next.js Docs: Layouts and Pages. - Next.js Docs: Mutating Data. - Auth.js Docs: Protecting Resources. ## 22. Next Lesson Preview Next, you will build a documentation website with nested navigation, MDX pages, search, metadata, and static generation.