react-antd-multi-tabs-admin, a lean React admin template with tabbed pages

A template written as a reaction to Ant Design Pro

This project is a React, TypeScript and Ant Design admin template, and the reason it exists is stated in the project's own introduction. The author had a multi-tab requirement in the work they were doing, looked through the templates available online, found that they were all based on Ant Design Pro, thought they were too heavy, and so rebuilt a leaner version from a framework they had used before.

That origin explains the shape of the codebase. The feature list is short and specific: multi-tab pages with a right-click menu, Redux and Toolkit state management with persistence, a wrapped axios request helper, dynamic chainable breadcrumb navigation, route and menu permission control, style isolation through less and CSS modules with tailwindcss classes available for simple styling, a list, pagination, multi-select and search component that work together, customisable webpack configuration with bundle optimisation, api request mocking through MSW, and single sign-on through OpenId Connect integration.

The stated principles are equally short. The project claims code scale as its own original and lean scaffold, argues for the leading edge by using React Hooks throughout and dropping class components, and sits on the Ant Design system for its look.

The audience is a frontend developer starting an internal admin tool who wants the tabbed-page pattern without inheriting a large framework's conventions. There is a live preview linked from the documentation, and a series of screenshots of the running application, so you can see the tab behaviour before reading any code.

One naming point to note up front, since the package metadata calls the package multi-tabs-admin, the repository is react-antd-multi-tabs-admin, and the description explicitly says this is the pure version and not Ant Design Pro.The installation is worth writing down separately, because the port in the documentation and the port in the script differ.

The installation sequence in the documentation is four commands.

$ npm install -g typescript
$ git clone https://github.com/hsl947/react-antd-multi-tabs-admin.git
$ yarn install
$ yarn start         # 访问 http://localhost:666

The global TypeScript install is listed first because the webpack and tsconfig setup expects it, the clone brings the source down, `yarn install` resolves the dependencies from the yarn.lock file at the repository root, and `yarn start` starts the development server, which the comment says to visit on port 666.

The scripts in the package metadata show what those commands actually run. The start script is `cross-env PORT=4200 react-app-rewired start`, so the port is set through cross-env rather than an environment file, and the build script is `react-app-rewired build`. The `config-overrides.js` file at the repository root is where you change the webpack configuration, which is the mechanism behind the customisable webpack and bundle optimisation item in the feature list.

The tab model, and what happens when you close one

The multi-tab behaviour is the core of the template, and the documentation shows the implementation in the file `src/components/common/tabPanes/index.tsx`.

The removal function is worth reading closely, because it encodes several decisions that a tabbed admin interface usually has to make. When a tab is closed, the code finds the index of the target in the panes array and splices it out. If the closed tab was not the active one, the active key stays as it was and the panes are stored. If the closed tab was the active one, the address moves backwards: it takes the path of the previous tab and pushes that onto the history.

The commented-out block inside that function is the more interesting part. It shows a plan to close the previous tab as well if the user has no permission for it, and to push the one before that instead. The code is commented out, and the surrounding comment explains the reason, that if the previous tab has no permission after the current one closes, it should be closed too. So the author wrote the permission-aware version, then disabled it.

That is the pattern across the permission feature. The documentation says you can comment out the permission functionality if you do not need it, and the shipped code shows the same thing: the `checkAuth` function in `src/pages/container/index.tsx` has its real body commented and returns true unconditionally, with a comment saying it always returns true.

So the honest summary is that the tab machinery works and the permission layer is scaffolding. A team that needs permissions writes them, and a team that does not can delete the stubs, which is arguably the right default for a template.

The state is kept as a list of panes and an active key, and both are persisted through a `storeTabs` call, so the tab set survives a reload.

Redux and Toolkit, with the state kept in slices

State management is Redux with Redux Toolkit, and the documentation is explicit that you can still use plain redux, since Toolkit is a wrapper around it. The reason given for Toolkit is to reduce Redux boilerplate, and the guidance is to split the code according to the principle of proximity, so a slice lives near the code that uses it.

The example slice in the documentation is in `src/store/slicers`, and it shows the shape of the pattern the template expects.

The slice in the documentation shows the pattern the template expects. It is named `app`, and the `AppState` interface holds three things: the theme name, whether the menu is collapsed, which is used for the vertical layout, and the menu mode, which is used for the horizontal layout. The initial state sets a dark theme, an expanded menu and horizontal mode, so the template opens in the configuration the screenshots show.

The `AppState` interface holds three things: the theme name, whether the menu is collapsed, which is used for the vertical layout, and the menu mode, which is used for the horizontal layout. The initial state sets a dark theme, an expanded menu and horizontal mode, so the template opens in the configuration the screenshots show.

The slice is then created with `createSlice`, named `app`, with a `setTheme` reducer shown in the example and a comment noting other setters would go alongside it. The actions are destructured from the slice, and the selectors are typed against `RootState` from the store, which is what the `import type { RootState } from '@/store'` line is for.

The persistence comes from redux-persist, listed in the dependencies alongside redux-promise for handling promise-shaped actions. The package metadata also includes react-redux at 7.2.6, so the store is wired the conventional way, and the `redux` package itself is still a direct dependency, which is what the note about continuing to be able to use redux refers to.

Routes drive the menu, and one file holds both

The routing and menu configuration is described in a short section, and the design decision in it is the interesting part.

All routes are written in `/src/route/routes.ts`, including the menu bar routes, and that file is used for route permission control. The menu is generated from the routes, with extra fields on a route entry marking whether it appears in the menu bar and which icon it uses. The documentation notes you can also write them separately if you want more customisation.

Generating the menu from the route table rather than maintaining two lists is the choice that makes a template like this maintainable. The alternative, two sources of truth, is where admin templates rot. The cost is that the route objects carry presentation fields, so a route entry is no longer a pure routing record.

The `src/components/common/menu/index.tsx` file is where that generation happens, and the documentation shows its `creatSubMenu` function. The commented-out original implementation filtered `data.routes` against a `permission` array, matching on the item key against the permission code, and only pushed a menu item when the filtered array was non-empty. The shipped version reduces over the routes and pushes every item, with a length check before returning the submenu, and a null return when there is nothing to render.

So the code is a before-and-after of the same decision. The commented version is the permission-aware menu, and the live version is the open menu.

The `config/` directory and `paths.json` at the repository root sit alongside this, and `config-overrides.js` is the webpack escape hatch. The feature list mentions customisable webpack configuration and bundle optimisation, and the presence of `config-overrides.js` at the root rather than a patched react-scripts config is the mechanism for that. The project uses `react-app-rewired` in its scripts, which is the tool that makes such overrides possible.

Theming is a less file swap, not a component API

The theming story is the part of the template that is most likely to cause friction, and it is worth understanding before you build on it.

The framework implements dynamic theme switching with less.js, with the JavaScript in `/public/less.min.js` and the theme configuration in `/public/color.less`. The documentation explains the consequence directly: once you have referenced Ant Design components you generally do not need to write extra theme styles yourself, because they are all in the theme file, but if you write a custom component, its styles will render incorrectly after a theme switch, and you need to add the corresponding dark and light styles at the bottom of color.less yourself.

That is a real maintenance commitment rather than a one-off. A template with a fixed colour scheme is done. A template with runtime theme switching means every custom component you add carries two style variants, and the second one is only discovered when a user flips the switch.

The README also notes that antd at the time of writing, 4.17.0-alpha.0, supported dynamic theming through its own custom theme variable documentation, described as experimental, and suggests trying it out. The pinned version in the package metadata is older than that, at antd 4.2.0, so the two are not the same thing and the version you install determines what the platform offers you.

The features list describes the dark mode theme and support for switching between dark and light. The nearest-plans section mentions that multi-theme colour switching or a colour picker for dynamic reskinning is under research, so the current state is a two-theme model, not an arbitrary palette.

For simple styling the template suggests tailwindcss classes as an alternative, and the repository root carries a `tailwind.config.js`, so the two styling approaches coexist: tailwind for utility work, less and CSS modules for the themed component layer.

React 17, antd 4 and IE11 in the browser support table

The dependency versions tell you what era this template comes from, and they are the first thing to check before you adopt it.

React and React DOM are at 17.0.2, antd is pinned at exactly 4.2.0, and the router is react-router-dom 5.3.0 with react-router-breadcrumbs-hoc 4.1.0 for the breadcrumb chain. The build is Create React App under `react-app-rewired`, with cross-env setting the port in the start script, and the browserslist in the package metadata targets more than 0.2 percent, not dead, not op_mini all for production, and the last version of Chrome, Firefox and Safari for development.

The supported environment table says modern browsers and IE11, with IE11 and Edge in the first column, Firefox, Chrome, Safari and Opera each at the last two versions.

The IE11 line is the tell. It dates the template to the period when IE11 support still shaped what people shipped, and it is inconsistent with the rest of the stack, though the later React 18 is the release that actually dropped IE11 support. Reading it as a target rather than an achievement, IE11 is listed as something the project wanted to cover.

The practical consequence for a new project in 2026 is that the pinned antd 4.2.0 is well behind the current antd major version, and the pinned React 17 means no React 18 concurrent features and no React 19. The template is a starting point you would upgrade rather than a base you would keep as is.

The upside of the older pins is a well-trodden combination. Every one of these packages is stable, the API surface you will read about is the API that exists in the pinned versions, and the ecosystem of blog posts and troubleshooting for this stack is deep. That matters more than currency for a template, because the code you copy out of it has to keep working.

What you get for free, and what you have to build

It is worth listing what the template actually hands you, because the feature list mixes scaffolding with finished components.

Finished and reusable: the tab pane system with its right-click menu, the wrapped axios helper so every request goes through one place, the dynamic chainable breadcrumb, the list, pagination, multi-select and search component that work together, the MSW mocking setup so you can develop against fake API responses, the OpenId Connect integration via oidc-client, the redux-persist wiring, and the less-based theme switching with the webpack override point.

Not finished: route and menu permission control. The documentation describes menu page route permission control as a feature, and the code that would implement it is present but commented out in the two places that matter, the menu generator and the container's `checkAuth` function. The documentation also says explicitly that if you do not need permission control you can comment it out yourself, which is a slightly odd framing given that it is already commented out in the shipped code.

The testing story is thin, and the project is honest about it. The near-plans section lists integrating unit testing with jest and enzyme and aiming for 100 percent coverage, marked as something being learned. The package metadata does include a test script wired to `react-app-rewired test`, and the dev dependencies include the Testing Library packages, so the scaffolding for React Testing Library is there, but the coverage goal is a stated intention rather than a description of the current state.

The last push to the repository was on 2026-07-06, and the project is not archived, with no tagged releases and the package version at 0.1.0 and marked private. The licence is MIT, with a LICENSE file at the top of the tree.

The template is best read as a working reference implementation of the tabbed admin pattern. Whether you keep it as a base or lift the tab code into your own scaffold, the tab and breadcrumb modules are the parts worth studying.

Editorial conclusion

This template suits a React team that wants multi-tab page navigation in an internal admin tool and would rather start from a small codebase than from Ant Design Pro. It does not suit a project that needs working route and menu permissions out of the box, because the documented permission checks are stubbed to return true, and it does not suit a team on React 18 or Ant Design 5, since the pinned versions are React 17 and antd 4.2.0. Verify first that the tab closing and breadcrumb behaviour matches what your users expect, that the stubbed permission helpers are replaced before the app faces real users, and that the antd version pinned in package.json is compatible with the components you intend to add.

Frequently asked questions

Official sources

1. hsl947/react-antd-multi-tabs-admin on GitHub
2. Issues
3. License: MIT
4. Project website
5. README