Frontend React Project Structure and Conventions

After working with React for over a year, I’ve gained some insights into React practices. While designing the frontend architecture for a new project, I reflected on the shortcomings and issues of previous projects and decided to improve and simplify the structure this time. I also researched mature designs and open-source projects, ultimately deciding to adopt the following structure.

Welcome to discuss and collaborate for mutual improvement.

Directory Planning

├── app
│   ├── action-types          
│   ├── actions
│   ├── api
│   ├── app.less
│   ├── app.tsx
│   ├── components
│   ├── config
│   ├── effects
│   ├── index.tsx
│   ├── reducers
│   ├── routes.tsx
│   ├── shared
│   ├── types
│   └── typings.d.ts
├── webpack
├── favicon.ico
├── i18n
├── index.html
├── manifest.webapp
├── mock-data
├── robots.txt
├── test
├── static
│   └── images
├── .editorconfig
├── .huskyrc
├── .prettierrc
├── tsconfig.json                 
├── tsconfig.test.json
├── tslint.json         
├── yarn.lock  

Thoughts Behind the Structure

The structure above might seem empty and simple, but behind it are some of my current thoughts. Let me highlight them here.

1. React is a library, not a framework, so it’s very flexible. This is its charm because you can use it however you want. But projects aren’t always personal projects - we sometimes need to establish boundaries to ensure the project’s organizational structure isn’t chaotic. So basic scaffolding and conventions are indeed necessary.

2. Since React itself isn’t a framework, there are no official suggestions or structural requirements. When working on actual projects, we need to determine a reasonable architecture based on the technology stack we adopt and actual business development scenarios.

3. The projects I’ve participated in use Redux. As we all know, the official recommendation is to split components into Components and Containers - presentational components and container components. I think this concept is correct. But in actual practice, I found that this separation can to some extent cause strongly related code to be forcibly separated. So in this architecture, I don’t plan to separate them into different folders. After all, they’re still React components, so they can all go directly under the components folder. As for internal separation of whether to connect to Redux, that’s optional.

4. editorConfig + tslint + husky safeguard basic code style and quality

Note: There’s no best, only better. In upcoming practices, I’ll continue to improve this based on actual situations and discovered issues. Welcome feedback from fellow developers.

Some Conventions

Besides the basic structure above, I’ve established the following conventions for the team:

• Folder names: lowercase, kebab-case naming, e.g., user-comment
• Component file class names: lowercase kebab-case naming
• Route-level component naming: add page suffix

Final Thoughts

I worked with Angular in 2018 and before, only starting to work with React in the past year due to project needs. Although there are syntactic differences, and one is a library while the other is a framework - admittedly, there are indeed many differences, and I was somewhat uncomfortable at first. But as I gradually delved deeper, there were actually many familiar points, like hooks, component communication, routing, etc. Until one day, I had an epiphany - yes, all methods lead to the same destination.

Learning technology is about learning thoughts and content. Don’t be deceived by superficial tricks. Let’s encourage each other.