nextjs-skeleton

This is a Next.js project bootstrapped with create-next-app, typescript, material-ui and sass

Requirements

NodeJS 14+

Developers guide

Setup:

npm install
npm run dev

Open http://localhost:3000 with your browser to see the result.

📃 Frontend conventions

Git usage agreements and IDE settings

Git usage agreements: (...define your rules...)
We use LF instead of CRLF
We use editorconfig, eslint, prettier and husky for the automatic code formatting and ensuring our code quality

Find the configs in the repository and don't forget to set up your working IDE environment to work with these configs

Project structure

./
├── pages/
├── common/
├── styles/
├── public/
├── types/
├── components/
│   ├── layouts/
│   ├── component-a/
│   ├── component-b/
│   └── component-c/
│       ├── index.ts
│       ├── component-name.tsx
│       └── component-name.module.scss
└── features/
    ├── feature-a/
    ├── feature-b/
    └── feature-c/
        ├── index.ts
        ├── feature-name.tsx
        ├── feature-name.test.tsx
        ├── feature-name.store.ts
        ├── feature-name.utils.ts
        ├── feature-name.data-access.ts
        └── feature-name.module.scss

pages/ - page wrapper components without business-logic, we are able to store here only routing settings, error handling and server-side data-fetching
common/ - shared utils, constants, helpers, etc.
styles/ - global styles
public/ - raw icons, fonts, images, and other assets
types/ - shared interfaces
components/ - shared reusable presentation components, icon components and layout components without business-logic and data-fetching
components/layouts/ - shared reusable layout components based on react layout pattern
features/ - feature-specific components with business-logic and client-side data-fetching (business domain layer)

*We use index files for the export components *Additionally, please react this article about implementation of react layout pattern.

Naming rules

We use business terms, names of back-end entities and component names from Figma to name our modules (according to "Domain Driven Design")
We use kebab-case for the file names
We use camelCase and PascalCase for the functions and classes
We use UPPERCASE for the constant names
In other cases we are guided by best practices

Testing

We write tests only for the basic usage cases of completed features and critical or algorithmically complex code sections For example completed feature component from "features/" folder or complicated helper function or utility should be covered by tests

State management

We use React local state and React context for the state management in ordinary situations
In other cases we are able to use browser storages, cache and other specific tools like SWR

Data-fetching

We use basic NextJS recommendations for the data-fetching

*Clarification:

In case of client-side data-fetching we should fetch data from feature-specific components (frontend/features) by using React hooks with wrapper for the Fetch API and SWR

In case of server-side data-fetching we should fetch data from page wrapper components (frontend/pages) by using getStaticProps and getServerSideProps with wrapper for the Fetch API

Adaptive and responsive web design concepts

We use "Responsive web design" concepts in accordance with our vision without using a grid

Pull requests

Pull request can be merged if there are 2 or more approvals
Pull request can only be merged by its initiator

CI/CD

...define your rules...

dmitrii-esin/nextjs-skeleton