Front-end components of the project file name and organization

April 2, 2019 19:25:06 w18478272407 Reads: 14

reason

In developing the project, we more or less have their own project directory structure of wondering, how to divide the module and how sensible naming, if these early projects did not take the time specification good, then come back new people will follow their own logic again divided in their catalog, so day after day, the project will not only increase the volume and directory structure will become increasingly chaotic, so it is necessary to focus the project has the file directory, the paper is out of this a starting point to write, take a look at the directory of several outstanding 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, containing only the src directory and public2.

@ View / cli




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

vue of cli is exactly 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

SPA with respect to the application, MPA application especially homogeneous applications, the directory structure is very clear.

So how do you organize files only reasonable?

The answer is component-based, component-core all the way to establish the appropriate file directory, there are several components division:

1, common components and business components:

Generally more common way is to divide a common component used immediately went on an upgrade, encountered a page component parts used, then it is possible to put a page with the same level may also be placed directly on the top level, for example, :




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

The advantage of this, then more flexible, but local public part of it is hard to define.

2, BEM components into

This word components into relatively clear.




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

The strong component score of three categories, although the structure is very clear on this, but in the process of project development you have to assembly between Block with Elemens move around frequently, reducing development experience.

3, the container assembly Display assembly




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

Here depends on how you define what is a container for components with Display components, and for the day to day development, this 2 person is not mandatory boundaries, you can switch freely between the two, but also not to say that certain components have to show pure components, does not necessarily mean the container assembly necessarily have to have a state with the life cycle, and for himself, a good guideline is to show components for decoupling, container components for cohesion.

4, the pattern assembly logic components

If the project useful tool to css-in-js such as styled-component, presumably think of style where to put this problem, so the following will happen:




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

This kind of logic will be more out of it.

Is there a way to standardize a unified directory good component of it?

The answer is yes, this is based on more than a few ways to divide, often develop when a component is likely to be identified as the styles of the component or components of the container, so this time we do not separate them, but all components directory on the components, and then divided according to the module, all the pages are combined by module assembly, the outermost layer is the page assembly should be simple and most of the small amount of 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 catalog, Profile Picture, information cards and login box scenarios, we define image, js, scss separately under each component directory, to do so, the individual components if you want to migrate, then you can very easily moved , here again that LoginBox following AreaList under, then LoginBox if you want to add functionality, then add directly in the component, but also easily expanded.

Finally, as for how to name files

This depends on how the provisions of the project team, but there is a general principle is that if it is the kind of thing must be capitalized, the example above me, because the components can also be seen as a class, so capital is relatively clear, as named assembly , there is a more popular way is called path-base-naming, is based on the file path name, such as naming AreaList at home / index.js inside, then you can do:




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

However, if the directory named in LoginBox no longer need so long.




import AreaList from './AreaList';

to sum up

Finally, based on this way sub-modules, developers can freely show the container component or components distributed in various folders into separate components, can be said to standardize and flexibility have been protected.

reference

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

Source: https://segmentfault.com/a/1190000018717822