首頁  >  文章  >  web前端  >  前端專案中目錄結構優化的方法總結

前端專案中目錄結構優化的方法總結

不言
不言原創
2018-09-17 14:22:382800瀏覽

這篇文章帶給大家的內容是關於前端專案中目錄結構優化的方法總結,有一定的參考價值,有需要的朋友可以參考一下,希望對你有幫助。

目錄結構優化

現在前端專案越來越變得像大型工程了,而且越來越複雜了,需要處理好組員之間的協作,也需要做好業務分塊、去耦合來降低維修成本,還要維持高效率開發。

工程目錄結構的最佳化是能達到這個目的的一種方式。一般而言,不是多頁面工程還是單一頁面應用,抑或二者都有,目錄結構都是以下兩種方式:

  1. 類型分組(依檔案類型、業務類型等進行分組)

  2. 模組分塊(依頁面模組、業務模組等分塊)

##1. 類型分組

這種方式是以文件類型、業務類型或其他類型進行分組。

多重頁面工程

|-- src/ 源代码目录

    |-- html/ html 文件目录
        |-- page1.html page1 页面的 html 文件
        |-- module1/ 子目录
            |-- page2.html page2 页面的 html 文件
            |-- ...
            
        |-- ...    
        
    |-- js/ js 文件目录
        |-- common/ 公共文件目录
        |-- page1/ page1 页面的 js 目录
        |-- module1/ 子目录
            |-- page2/ page2 页面的 js 目录
            |-- ...
            
        |-- ...
        
    |-- css/ css 文件目录
        |-- common/ 公共文件目录
        |-- page1/ page1 页面的 css 目录
        |-- module1/ 子目录
            |-- page2/ page2 页面的 css 目录
            |-- ...
            
        |-- ...
        
    |-- less/ less 文件目录(内部结构跟上面类似)
    |-- images/ 图片文件目录(内部结构跟上面类似)
    |-- data/ api-mock 文件目录(内部结构跟上面类似)
    |-- ...

#單一頁面應用程式##

|-- src/ 源代码目录
    |-- components/ 组件文件目录(如 react)
        |-- common/ 公共文件目录
        |-- page1.js page1 页面的组件文件
        |-- module1/ 子目录
            |-- page2.js page2 页面的组件文件
            |-- ...
            
        |-- ...    
        
    |-- services/ service 文件目录
        |-- service1.js page1 页面的 service
        |-- module1/ 子目录
            |-- service2.js page2 页面的 service
            |-- ...
            
        |-- ...
        
    |-- models/ model 文件目录
        |-- model1.js page1 页面的 model
        |-- module1/ 子目录
            |-- model2.js page2 页面的 model
            |-- ...
            
        |-- ...
        
    |-- ...
    
|-- images/ 图片文件目录(内部结构跟上面类似)
|-- data/ api-mock 文件目录(内部结构跟上面类似)
|-- ...
這種方式的優點是能使文件分類、功能分類非常清晰,並且能夠在一定程度上約束組員的書寫方式(目錄結構),也清晰明了、簡單易懂。但這種方式有很明顯的缺點:

    不能很簡單快速的知道某個頁面或某個功能塊有哪些檔案;
  1. 建立、更新、刪除頁面會變得很低效,因為需要到不同文件類別目錄去找文件;
  2. #開發效率不高,而且很容易疲勞,因為編輯一個頁面的時候需要在編輯器的文件導覽中展開各個文件,導覽就會非常長。
  3. 所以,對前端專案而言,多數情況下我不會使用這種目錄結構。

2. 模組分塊

這種方式是以頁面模組、業務模組或其他類型進行分塊。

多重頁面工程

|-- src/ 源代码目录

    |-- page1/ page1 页面的工作空间
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 样式入口文件
        |-- html/ html 片段目录
        |-- js/ js 文件目录
        |-- (css|less|scss)/ 样式文件目录
        |-- data/ 本地 json 数据模拟
        |-- images/ 图片文件目录
        |-- components/ 组件目录(如果基于 react, vue 等组件化框架)
        |-- ...
        
    |-- module1/ 子目录
        |-- page2/ page2 页面的工作空间(内部结构跟 page1 类似)
        
    |-- ...
    
|-- html/ 公共 html 片段
|-- less/ 公共 less 目录
|-- components/ 公共组件目录
|-- images/ 公共图片目录
|-- data/ 公共 api-mock 文件目录
|-- ...

#單一頁面應用程式##

|-- src/ 源代码目录
    |-- page1/ page1 页面的工作空间
        |-- index.js 入口文件
        |-- service.js
        |-- model.js
        |-- data/ 本地 json 数据模拟
        |-- images/ 图片文件目录
        |-- components/ 组件目录(如果基于 react, vue 等组件化框架)
        |-- ...
        
    |-- module1/ 子目录
        |-- page2/ page2 页面的工作空间(内部结构跟 page1 类似)
        
    |-- ...
    
|-- images/ 公共图片目录
|-- data/ 公共 api-mock 文件目录
|-- components/ 公共组件目录   
|-- ...
這種方式避免了「類型分組」的問題,但也有一些不足:

對組員的限制很小,每個工作空間下的目錄結構可以完全不一樣;
  1. 工作空間下的目錄結構不是很容易定義好,對開發人員等級要求要高一些。
  2. 儘管有些不足,但可以配合建置工具消除,所以一般情況下我會選擇這種目錄結構。
3. 搭配使用

很多情況下,這兩種方式是可以配合使用的,例如多頁面工程中有小型單頁應用。

|-- src/ 源代码目录

    |-- page1/ page1 页面的工作空间
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 样式入口文件
        |-- html/ html 片段目录
        |-- js/ js 文件目录
            |-- ajax/ 对 ajax 封装的目录
            |-- util/ 工具类函数的目录
            |-- pages/ spa 应用页面目录
            |-- data/ 静态数据目录
            |-- tpl/ 模板目录
            |-- (event|view)/ 事件监听文件目录
            |-- ...
        |-- data/ 本地 json 数据模拟
        |-- (css|less|scss)/ 样式文件目录
        |-- images/ 图片文件目录
        |-- components/ 组件目录(如果基于 react, vue 等组件化框架)
        |-- ...
        
    |-- ...

以上是前端專案中目錄結構優化的方法總結的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn