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

Here are 3 architecture lessons I learned while building it.

1) I stopped doing “fetch inside useEffect” everywhere (RTK Query made it clean)

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.

The shift

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.

2) Dashboards are a “layout game” (I learned the Three‑Pane UI pattern)

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 layout trick that finally made it work

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.

3) I learned route security is not just “hide the menu” (RBAC needs structure)

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" && <AdminMenuItem />}

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 <Navigate to="/login" />;
  if (!allowedRoles.includes(user.role)) return <Navigate to="/unauthorized" />;

  return element;
};

This made the app feel safer and cleaner.

The takeaway (from a beginner’s perspective)

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.