Reason

In the process of developing a project, people are more or less doubtful about the catalogue structure of their own project, how to divide modules reasonably and how to name them reasonably. If these are not well regulated in the early stage of the project, then the newcomers will divide their catalogues again according to their own logic, so that the volume of the project day after day will not only meet. Increase and the directory structure will become more and more chaotic, so it is necessary to focus on the project file directory, this article is also written from such a starting point, first look at the catalogue of several excellent projects.

crate-react-app

├── package.json
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── Lazy.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js

create-react-app is very simple and contains only two directories, src and public.

@vue/cli

├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
└── src
    ├── App.vue
    ├── assets
    │   └── logo.png
    ├── components
    │   └── HelloWorld.vue
    └── main.js

The cli of vue is the same.

nuxt

├── assets
├── components
│   └── Logo.vue
├── layouts
│   └── default.vue
├── middleware
├── nuxt.config.js
├── package-lock.json
├── package.json
├── pages
│   └── index.vue
├── plugins
├── server
│   └── index.js
├── static
│   └── favicon.ico
└── store

Compared with SPA applications, MPA applications, especially isomorphic applications, directory structure is also very clear.

So how to organize documents is reasonable?

The answer is componentization. Everything takes components as the core to establish the corresponding file directory. There are several ways to divide components:

1. Common Components and Business Components:

Generally, the most commonly used way of partitioning is to upgrade the components that are used for public use. If you encounter some components that are used for pages, they may be placed at the same level as the pages or directly at the top level, for example:

├── common
│   ├── Footer
│   ├── Header
│   └── Slider
└── pages
    ├── _common
    │   └── banner
    ├── index
    └── info

This advantage is flexible, but it's hard to define the local public part.

2. BEM Component Partition

In this case, the component division is relatively clear.

├── Blocks
│   ├── Avatar
│   │   ├── index.js
│   ├── Button
│   │   ├── index.js
│   ├── Header
│   │   ├── index.js
│   │   └── style.scss
├── Elements
│   ├── DownloadBtn.js
│   ├── Logo.js
└── Icons
    ├── Audience.js

Although the structure is very clear, you have to move components frequently between Block and Elemens in the process of project development, which reduces the development experience.

3. Container Components and Display Components

├── components
│   ├── Banner
│   ├── Footer
│   └── Header
├── containers
│   ├── ArticleDetail
│   └── CommentList
└── screens
    └── home

It depends on how you define container components and display components. For daily development, there is no compulsory boundary between them. They can be switched freely. It does not mean that display components must be pure components, or that container components must be stateful and lifecycle. For me, a good rule is that container components must have state and lifecycle. The display component is for decoupling and the container component is for cohesion.

4. Style Components and Logic Components

If you use tools such as css-in-js in your project, such as styled-component, you will think about where style is placed, and then the following will happen:

./
└── Avatar
    ├── index.js
    └── styles
        └── styleWrapper.js

This leads to an additional logic.

So is there a unified way to regulate the file directory of components?

The answer is yes, this is based on the above several partitioning methods. Usually when developing a component, it may be recognized as a style component or container component. Then we will not separate them. Instead, all the components are placed under the components directory, and then partitioned according to the module. All the pages are composed by module components, and the outermost pages are composed by module components. Face components should be the most concise and less code. As follows:

├── components
│   └── User
│       ├── Avatar
│       │   ├── images
│       │   ├── index.js
│       │   └── style.scss
│       ├── InfoCard
│       │   ├── images
│       │   ├── indexjs
│       │   └── style.scss
│       └── LoginBox
│           ├── reaList
│           │   ├── images
│           │   ├── index.js
│           │   └── style.scss
│           ├── index.js
│           └── style.scss
└── screens
    └── home
        └── index.js

For example, in the user module directory, there are avatars, information cards and login boxes. We limit image, js and scss to each component directory. In this way, a single component can be easily moved if it wants to migrate. Here's a list of AreaList s under LoginBox. If LoginBox wants to add functionality, it's right here. Components are added and expanded very easily.

Finally, how to name a file

This depends on how the project team specifies it, but there is a general principle that if it is a class, it must be capitalized. In my example, since components can also be considered as a class, capitalization is relatively clear. As for component naming, there is a popular way to name components, called path-base-naming, which is based on file paths, such as the name AreaLi in home/index.js. If st is the case, it can be as follows:

import LoginBoxAreaList from '../../components/LoginBox/AreaList';

But if you name it in the LoginBox directory, you don't need that long anymore.

import AreaList from './AreaList';

summary

Finally, based on this sub-module approach, developers can freely distribute container components or display components in separate component folders, which can be said that both specifications and flexibility are guaranteed.

Reference resources

https://medium.com/@dan_abram...
https://hackernoon.com/struct...