Building an Enterprise Dashboard : 3 Architecture Lessons That Clicked
Source: Dev.to
⚠️ Collection Error: Content refinement error: Error: 429 “you (bkperio) have reached your weekly usage limit, upgrade for higher limits: https://ollama.com/upgrade (ref: df4559dd-94a6-4af9-b1e9-2d03c76fd2a7)”
I’ve been learning React recently,and I build something that pushed me to learn a lot - an enterprise-style dashboard. It had the stuff dashboards usually have: big data tables filters that actually matter layouts with sidebars routes that should be locked down based on role And that’s when I realized something:
the way we write React in beginner tutorials doesn’t scale cleanly to dashboards. Here are 3 architecture lessons I learned while building it. At the start, my instinct was the usual: put fetch() inside useEffect
manage isLoading, isError
store data in local state repeat the same pattern in multiple components That works fine… until you add filters. In my “Quality Checks” table, the user could switch tabs and apply filters, and the data needed to refresh smoothly. Doing this manually started getting messy fast - lots of repeated code and state handling. So I switched to RTK Query. What I liked most as a beginner was:
I didn’t have to manually manage loading + caching logic everywhere.
Instead of writing fetch logic inside the component, I created a centralized API slice:
// features/api/apiSlice.ts
export const apiSlice = createApi({
reducerPath: “api”,
baseQuery: fetchBaseQuery({ baseUrl: “http://localhost:3001” }),
tagTypes: [“QualityCheck”],
endpoints: (builder) => ({
getQualityChecks: builder.query({
query: (filters) => /qualityChecks?status=${filters.status},
providesTags: [“QualityCheck”],
}),
}),
});
Then in the component, it becomes super simple: const { data: records = [], isLoading } = useGetQualityChecksQuery({ status: activeTab });
Now when activeTab changes, the request updates automatically. No useEffect dependency confusion.
No duplicated loading state logic.
It just… behaves like a dashboard should. Most beginner projects are simple pages that scroll normally. Dashboards are different. In enterprise UIs, navigation should stay visible while the data area scrolls. So I built a three‑pane layout: Primary sidebar (modules) Secondary sidebar (sub-navigation) Main content (filters + table)
The biggest lesson was keeping layout styling separate from component styling. The layout needed to: lock the overall screen height (100vh) stop the browser from scrolling the entire page allow scrolling only inside the table/content section So the root layout uses something like: display: flex
height: 100vh
overflow: hidden
…and only the content area gets: overflow-y: auto
Once I did that, the UI suddenly felt like a real tool instead of a normal webpage. This was a big one. In a real dashboard: Admins might access configuration screens Operators might only access production/quality screens Some routes should be completely blocked based on role At first, it’s tempting to do random checks like: {user.role === “admin” && }
But the problem is: it spreads role logic everywhere you can easily forget a screen someone can still type the URL directly if routes aren’t protected So instead, I made one place where permissions are defined (a route/menu config), and protected routes using a wrapper. const ProtectedRoute = ({ element, allowedRoles }) => { const user = useSelector(selectCurrentUser);
if (!user) return ; if (!allowedRoles.includes(user.role)) return ;
return element; };
This made the app feel safer and cleaner. Also, it’s easier to scale:
If a new role comes later (like “Manager”), you don’t rewrite the whole app - you update the config + allowed roles.
Building this dashboard taught me that React isn’t only about components. At dashboard level, you start thinking about: data fetching patterns
layout structure
role-based access
and writing code that won’t collapse when features grow If you’re early in React learning like me, try building a dashboard with mock data (seriously, json-server helps a lot). A dashboard forces you to learn the “real stuff” naturally.