摘要：组件划分这种的话组件划分的比较清晰。将组件强势得分为类，这种结构上虽然非常清晰，但是在项目开发的过程中你不得不频繁地将组件在跟之间移来移去，降低了开发体验。
缘由
在开发项目的过程中，大家多多少少会对自己项目的目录结构产生疑惑，如何合理地划分模块以及如何合理的命名，这些如果在项目前期的时候没有好好规范好的话，那么后面新进来的人便会按照自己的逻辑又重新在划分自己的目录，这样日复一日项目体积不但会增加而且目录结构会越来越混乱，因此非常有必要聚焦项目的文件目录，本文也是出于这样的一个出发点来写的，先来看看几个优秀项目的目录。
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是非常的简洁，只包含了src以及public2个目录。
@vue/cli├── package.json
├── public
│ ├── favicon.ico
│ └── index.html
└── src
├── App.vue
├── assets
│ └── logo.png
├── components
│ └── HelloWorld.vue
└── main.js
vue的cli也是如出一辙。
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应用，MPA应用特别是同构应用来说，目录结构也是很清晰的。
那么如何组织文件才合理呢？答案便是组件化，一切以组件为核心来建立相应的文件目录，这里有几种划分组件的方式：
1、公共组件与业务组件：一般比较常用的划分方式便是有公共用到的组件便往上提升一级，遇到部分页面用到的组件的话有可能放到跟页面同级也有可能直接放到最上面的一级，例如：
├── common
│ ├── Footer
│ ├── Header
│ └── Slider
└── pages
├── _common
│ └── banner
├── index
└── info
这种优点的话比较灵活，但是局部的公共部分你很难去界定。
2、BEM组件划分这种的话组件划分的比较清晰。
├── Blocks
│ ├── Avatar
│ │ ├── index.js
│ ├── Button
│ │ ├── index.js
│ ├── Header
│ │ ├── index.js
│ │ └── style.scss
├── Elements
│ ├── DownloadBtn.js
│ ├── Logo.js
└── Icons
├── Audience.js
将组件强势得分为3类，这种结构上虽然非常清晰，但是在项目开发的过程中你不得不频繁地将组件在Block跟Elemens之间移来移去，降低了开发体验。
3、容器组件与展示型组件├── components
│ ├── Banner
│ ├── Footer
│ └── Header
├── containers
│ ├── ArticleDetail
│ └── CommentList
└── screens
└── home
这里就要看你怎么定义什么是容器组件跟展示型组件了，对于日常的开发来说，这2者是没有强制的边界的，两者之间可以随意切换，也并不是说展示组件一定非得是纯组件，也不一定是说容器组件一定非得有状态跟生命周期，而对于本人来说，一个很好的准则就是展示组件是为了解耦，容器组件是为了内聚。
4、样式组件与逻辑组件如果项目中有用到css-in-js之类的工具，如styled-component，想必会想到样式放在哪里这个问题，于是便会出现如下情况：
./
└── Avatar
├── index.js
└── styles
└── styleWrapper.js
这就会多出来一种逻辑出来。
那么有没有统一的一种方式来规范好组件的文件目录呢？答案是有的，这种是基于以上几种划分方式来的，通常开发一个组件的时候有可能被认定为样式组件或者容器组件，那么我们这时就不把它们分开，而是所有的组件都放在components目录下面，再根据模块进行划分，所有的页面都是通过模块组件进行组合，最外层的页面组件则是应该是最简洁以及少代码量的。如下：
├── 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
例如在用户模块这个目录下，有头像、信息卡以及登陆框的情景，我们限定image、js、scss分别在每个组件目录下，这样做的话，单个组件如果要迁移的话就可以非常方便的移动了，这里再说明下LoginBox下面的AreaList，如果再LoginBox要添加功能的话，那么直接就在这个组件添加，也非常方便地扩展了。
最后至于文件如何命名这个要看项目组如何规定，但有个通用原则是如果是类的话必须是首字母大写，我上面的例子，由于组件也可以看成是一个类，因此大写是比较清晰的，至于组件的命名，有个比较流行的方式叫path-base-naming,就是基于文件路径来命名，例如在home/index.js 里面命名AreaList的话就可以这样：
import LoginBoxAreaList from "../../components/LoginBox/AreaList";
但如果在LoginBox目录下命名就不再需要这么长了.
import AreaList from "./AreaList";总结
最后基于这种分模块的方式，开发者可以自由的将容器组件或者展示组件分布在各个独立的组件文件夹之中，可以说规范和灵活性都得到了保障。
参考https://medium.com/@dan_abram...
https://hackernoon.com/struct...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/109266.html
摘要：作为一个库，它没有规定项目的整体结构。位于的组件应命名为。组件根据其与组件或的相对路径进行相应命名。考虑这样一个场景，处于位置的组件会被命名为而不是。 React 作为一个库，它没有规定项目的整体结构。这很好，因为它给了我们自由去尝试不同的方法，并适应更适合我们的方式。另一方面，这可能会给React领域的开发人员带来一些困惑。 我将会在本文为大家展示我已经使用过一段时间并且效果不错的方...
摘要：父类为，代表着一系列文章的列表。对于可读性较好地与代码，不应该像一本书，而应该像一个故事，一个故事中会存在角色和角色之间的关系，而这种更多的语义化地可以较好地提示你整个代码的可维护性。无论哪种文件组织方式比较顺眼，你都应该遵循统一的原则。 原文地址。本文从属于Web 前端入门与最佳实践。 CSS的学习是一个典型的低门槛，高瓶颈的过程，第一次接触CSS的时候觉得一切是如此简单，直到后面越...
阅读 2927·2021-11-23 09:51
阅读 1634·2021-10-15 09:39
阅读 1041·2021-08-03 14:03
阅读 2850·2019-08-30 15:53
阅读 3425·2019-08-30 15:52
阅读 2458·2019-08-29 16:17
阅读 2672·2019-08-29 16:12
阅读 1626·2019-08-29 15:26
