# # reason in the process of development, we will more or less about their project directory structure wondering, how to reasonably divide module naming, as well as how these if there is no good in the early stage of the project specification right, then people will be in accordance with their own new came in behind logic is back in his own directory, divided into As the size of the project grows and the directory structure becomes more and more chaotic, it is necessary to focus on the directory of the project. This article is written with this in mind.

create-react-app

├ ─ ─ package. Json ├ ─ ─ public │ ├ ─ ─ the favicon. Ico │ ├ ─ ─ index. The HTML │ └ ─ ─ the manifest. Json └ ─ ─ the SRC ├ ─ ─ App. CSS ├ ─ ─ App. Js ├ ─ ─ App.test.js ├── Lazy.js ├─ index.css ├── logo.svg ├─ serviceworker.jsCopy the code

Create-react-app is very compact, containing only SRC and public. SRC

@vue/cli

├ ─ ─ package. Json ├ ─ ─ public │ ├ ─ ─ the favicon. Ico │ └ ─ ─ index. The HTML └ ─ ─ the SRC ├ ─ ─ App. Vue ├ ─ ─ assets │ └ ─ ─ logo. The PNG ├ ─ ─ ├ ─ ├ ─ sci-molecular.sci-molecular.txtCopy the code

Vue’s CLI is the same.

nuxt

├── Assets ├── ├─ Logo. Vue ├── ├── Middleware ├─ ├── All exercises, ├─ all exercises, ├─ all exercises, all exercises, all exercises, all exercises, all exercises, all exercises, all exercises The favicon. Ico └ ─ ─ storeCopy the code

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

So how do you organize your files properly?

The answer is componentization, building directories around components. There are several ways to divide components:

1. Common Components and Business Components:

The most commonly used division is that there is a common use of components to upgrade one level, encounter parts of the page used components may be placed at the same level with the page may also be directly placed on the top level, for example:

├ ─ ─ common │ ├ ─ ─ Footer │ ├ ─ ─ the Header │ └ ─ ─ the Slider └ ─ ─ pages ├ ─ ─ _common │ └ ─ ─ banner ├ ─ ─ index └ ─ ─ the infoCopy the code

This kind of advantage is flexible, but the local public part is hard to define.

2. BEM component division

This way the components are divided more clearly.

├ ─ ─ Blocks │ ├ ─ ─ Avatar │ │ ├ ─ ─ index. The js │ ├ ─ ─ Button │ │ ├ ─ ─ index. The js │ ├ ─ ─ the Header │ │ ├ ─ ─ index. The js │ │ └ ─ ─ style.css. SCSS ├ ─ ─ Elements │ ├ ─ ─ DownloadBtn. Js │ ├ ─ ─ Logo. The js └ ─ ─ the Icons ├ ─ ─ on jsCopy the code

The component strength score is 3, which is very clear structurally, but you have to move components frequently between blocks and Elemens during project development, which reduces the development experience.

3. Container components and presentation components

├ ─ ─ components │ ├ ─ ─ Banner │ ├ ─ ─ Footer │ └ ─ ─ the Header ├ ─ ─ containers │ ├ ─ ─ ArticleDetail │ └ ─ ─ CommentList └ ─ ─ screens └ ─ ─ the homeCopy the code

Here depends on how you define what is a container component to display components, for the development of daily, this is not mandatory border, the two can freely switch between, also is not to say that the display components have to be in pure components, does not necessarily mean container components necessarily stateful and life cycle, and for himself, A good rule of thumb is to present components for decoupling and container components for cohesion.

4. Style and logic components

If a csS-in-js tool, such as styled-component, is used in your project, you will think about where the style is placed, and the following will occur:

├─ ├─ style ├─ ├.htmCopy the code

So that’s one more kind of logic.

So is there a unified way to regulate component file directories?

The answer is yes, this is based on the above several classified methods, often develop a component could be identified as style components or container components, so we don’t separate them at this moment, but all of the components in the components directory below, and then according to the module division, all pages are to be carried out through the module component combination, The outermost page component should be the simplest and least code-intensive. As follows:

├ ─ ─ components │ └ ─ ─ the User │ ├ ─ ─ Avatar │ │ ├ ─ ─ images │ │ ├ ─ ─ index. The js │ │ └ ─ ─ style.css. SCSS │ ├ ─ ─ InfoCard │ │ ├ ─ ─ images │ │ ├ ─ ─ indexjs │ │ └ ─ ─ style.css. SCSS │ └ ─ ─ LoginBox │ ├ ─ ─ reaList │ │ ├ ─ ─ images │ │ ├ ─ ─ index. The js │ │ └ ─ ─ style.css. SCSS │ ├ ─ ─ │ ├ ─ 07.txt ├ ─ 07.txtCopy the code

For example, in the user module directory, there are pictures, information cards and login boxes. We limit image, JS and SCSS to each component directory. In this way, it is very convenient to move individual components if they want to migrate. If LoginBox needs to add functionality, it can be added directly to this component and easily extended.

Finally, how to name the file

It depends on the project team, but the general principle is that a class must have a capital letter. In my example above, since a component can also be regarded as a class, the capital letter is relatively clear. As for component naming, there is a popular way called path-base-naming, which is named based on the file path. For example, you can name AreaList in home/index.js like this:

import LoginBoxAreaList from '.. /.. /components/LoginBox/AreaList';
Copy the code

But if you’re in the LoginBox directory, it doesn’t have to be that long.

import AreaList from './AreaList';
Copy the code

conclusion

Finally, with this modular approach, developers can freely distribute container or presentation components into separate component folders, which can be said to ensure both specification and flexibility.

reference

medium.com/@dan_abramo… Hackernoon.com/structuring…