Maison  >  Article  >  interface Web  >  Résumé des méthodes d'optimisation de la structure des répertoires dans les projets front-end

Résumé des méthodes d'optimisation de la structure des répertoires dans les projets front-end

不言
不言original
2018-09-17 14:22:382813parcourir

Ce que cet article vous apporte est un résumé des méthodes d'optimisation de la structure des répertoires dans les projets front-end. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Optimisation de la structure des répertoires

De nos jours, les projets front-end s'apparentent de plus en plus à des projets à grande échelle, et ils deviennent de plus en plus complexes. La collaboration entre les membres de l'équipe doit être bien gérée. , et les affaires doivent être bien menées. Le blocage et le découplage réduisent les coûts de maintenance tout en maintenant un développement à haute efficacité.

L'optimisation de la structure du répertoire du projet est un moyen d'atteindre cet objectif. De manière générale, qu'il s'agisse d'un projet multipage ou d'une application monopage, ou les deux, la structure des répertoires est la suivante :

  1. Regroupement de types (par type de fichier, métier type, etc. Regroupement)

  2. Bloc module (par module de page, module métier, etc.)

1.

Cette méthode consiste à regrouper par type de fichier, type d'entreprise ou autres types.

Projet multipage

|-- 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 文件目录(内部结构跟上面类似)
    |-- ...

Application d'une seule page

|-- 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 文件目录(内部结构跟上面类似)
|-- ...
L'avantage de cette méthode est qu'elle peut rendre la classification des fichiers et la classification des fonctions très claires, et elle peut contraindre dans une certaine mesure la méthode d'écriture (structure de répertoire) des membres de l'équipe, ce qui est également clair et facile comprendre. Mais cette méthode présente des inconvénients évidents :

  1. Il n'est pas facile et rapide de savoir quels fichiers possède une certaine page ou un certain bloc fonctionnel

  2. Création ; , la mise à jour et la suppression de pages deviendront très inefficaces car vous devrez accéder à différents répertoires de catégories de fichiers pour trouver des fichiers

  3. L'efficacité du développement n'est pas élevée et il est facile de se fatiguer car ; éditeurs Lorsque vous travaillez sur une page, vous devez développer chaque fichier dans la navigation des fichiers de l'éditeur, et la navigation sera très longue.

Donc, pour les projets front-end, dans la plupart des cas, je n'utiliserai pas cette structure de répertoires.

2. Blocage de modules

Cette méthode est divisée en modules de page, modules métiers ou autres types.

Projet multipage

|-- 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 文件目录
|-- ...

Application d'une seule page

|-- src/ 源代码目录
    |-- page1/ page1 页面的工作空间
        |-- index.js 入口文件
        |-- service.js
        |-- model.js
        |-- data/ 本地 json 数据模拟
        |-- images/ 图片文件目录
        |-- components/ 组件目录(如果基于 react, vue 等组件化框架)
        |-- ...
        
    |-- module1/ 子目录
        |-- page2/ page2 页面的工作空间(内部结构跟 page1 类似)
        
    |-- ...
    
|-- images/ 公共图片目录
|-- data/ 公共 api-mock 文件目录
|-- components/ 公共组件目录   
|-- ...
Cette méthode évite le problème du "regroupement de types", mais elle présente également quelques inconvénients :

  1. Les contraintes sur les membres du groupe sont très faibles et la structure des répertoires sous chaque espace de travail peut être complètement différent ;

  2. La structure des répertoires sous l'espace de travail n'est pas facile à définir et les exigences pour les développeurs sont plus élevées.

Bien qu'il y ait quelques défauts, ils peuvent être éliminés à l'aide d'outils de build, donc généralement je choisirai cette structure de répertoires.

3. Utiliser ensemble

Dans de nombreux cas, ces deux méthodes peuvent être utilisées ensemble, comme dans le cas de petites applications d'une seule page dans des projets multipages.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn