資訊專欄INFORMATION COLUMN
摘要：組件劃分這種的話組件劃分的比較清晰。將組件強勢得分為類，這種結構上雖然非常清晰，但是在項目開發的過程中你不得不頻繁地將組件在跟之間移來移去，降低了開發體驗。
緣由
在開發項目的過程中，大家多多少少會對自己項目的目錄結構產生疑惑，如何合理地劃分模塊以及如何合理的命名，這些如果在項目前期的時候沒有好好規范好的話，那么后面新進來的人便會按照自己的邏輯又重新在劃分自己的目錄，這樣日復一日項目體積不但會增加而且目錄結構會越來越混亂，因此非常有必要聚焦項目的文件目錄，本文也是出于這樣的一個出發點來寫的，先來看看幾個優秀項目的目錄。
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...
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/109266.html
摘要：作為一個庫，它沒有規定項目的整體結構。位于的組件應命名為。組件根據其與組件或的相對路徑進行相應命名。考慮這樣一個場景，處于位置的組件會被命名為而不是。 React 作為一個庫，它沒有規定項目的整體結構。這很好，因為它給了我們自由去嘗試不同的方法，并適應更適合我們的方式。另一方面，這可能會給React領域的開發人員帶來一些困惑。 我將會在本文為大家展示我已經使用過一段時間并且效果不錯的方...
摘要：父類為，代表著一系列文章的列表。對于可讀性較好地與代碼，不應該像一本書，而應該像一個故事，一個故事中會存在角色和角色之間的關系，而這種更多的語義化地可以較好地提示你整個代碼的可維護性。無論哪種文件組織方式比較順眼，你都應該遵循統一的原則。 原文地址。本文從屬于Web 前端入門與最佳實踐。 CSS的學習是一個典型的低門檻，高瓶頸的過程，第一次接觸CSS的時候覺得一切是如此簡單，直到后面越...
閱讀 2949·2021-11-23 09:51
閱讀 1666·2021-10-15 09:39
閱讀 1056·2021-08-03 14:03
閱讀 2880·2019-08-30 15:53
閱讀 3437·2019-08-30 15:52
閱讀 2487·2019-08-29 16:17
閱讀 2788·2019-08-29 16:12
閱讀 1647·2019-08-29 15:26
