Project structure

How to find your way in the project.

Saas UI Pro is setup as a monorepo which is managed by Yarn v3 and Turbo Repo.

The folder structure looks as following:

saas-uiAll Saas UI Pro packages and components live in here.
appsExample apps are in this folder.
apps/webNext.js frontend app.
apps/web/src/features/commonThe app's common functionality, for example layouts, that is shared across features.
apps/web/src/features/*Domain specific code is grouped within individual features.
apps/desktopNextron (Electron + Next.js) desktop app.
packagesThis contains all shared application code, as well as your own custom packages.
packages/api-clientThe API client used to fetch data (re-exports demo-client by default).
packages/api-demo-clientDemo client that returns mocked data for the demo application
packages/common-mocksMocked data used for the demo, and for testing purposes.
packages/common-i18nI18n helpers, using React Intl
packages/app-configContains all client side configuration files.
packages/app-nextjsNext.js specific utility functions and hooks.
packages/db-prismaPrisma client and schema.
packages/ui-libThis is your shared UI library, and included all custom pre-built components
packages/ui-storybookYour storybook.
packages/ui-themeYour custom Chakra UI theme. This extends the Saas UI Pro theme by default.
tooling/test-utilsHelper functions for testing.

Package naming#

Packages that are prefixed with app contain frontend application code. Your UI library related codes lives in ui prefixed packages. API related code lives in api prefixed packages.


Application code is grouped by feature, this means that all related assets, like components, hook, pages are grouped in a single feature folder. This setup will help to keep the code base maintainable as it (and your team) grows. It will make it easier to add/remove new features and prevent any unwanted side effects when refactoring or removing functionality, due to too much interdependencies.

A few rules to make sure the codebase stays maintainable.

  • Shared functionality is located in the common feature, other features can import from here.
  • Treat features as standalone packages, only import from the top-level barrel (index.ts) file. Eg import { BillingStatus } from '@app/features/billing.
  • If a component is used in multiple features and doesn't depend on external state (like data fetching), consider adding it to the ui library, otherwise add it to the common feature.
  • Keep components clean, eg if there is complex business logic, like useQuery or useMutation hooks, move them into a separate hook in hooks/

Was this helpful?