プロジェクトファイル名と組織のフロントエンドコンポーネント

2019年4月2日19時25分06秒 w18478272407は読み込み：14

理由

プロジェクトの開発では、我々は、多かれ少なかれ、その後、これらの初期のプロジェクトは時間指定の良いをしていない場合は、モジュールを分割し、どのように賢明な命名方法を、不思議の自分のプロジェクトのディレクトリ構造を持つ新しい戻ってきます人々は再び自分自身の論理に従ってそのカタログに分け、その日一日の後に、プロジェクトが唯一のボリュームを増加させず、ディレクトリ構造がますます混沌となりますので、プロジェクトファイルのディレクトリを持って集中する必要があるだろう、紙は、この外にあります書くための出発点は、いくつかの優れたプロジェクトのディレクトリを見てみましょう。

クレート反応するアプリ




├── 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

作成反応するアプリのみsrcディレクトリとpublic2を含む、非常に簡単です。

@ビュー/ CLI




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

CLIのVUEはまったく同じです。

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

三つのカテゴリーの強力なコンポーネントスコア、構造は、この上の非常に明確であるが、プロジェクトの開発の過程で、あなたはElemensとブロック間のアセンブリに持っているが、開発の経験を減らすこと、頻繁に動き回ります。

図3に示すように、容器アセンブリディスプレイアセンブリ




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

ここでは、ディスプレイのコンポーネントとコンポーネントのコンテナが何であるかをどう定義するかに依存しており、一日の開発に一日のために、この2人は必須境界は、次の2つの間を自由に切り替えることができませんが、また、特定のコンポーネントを示さなければならないということではありません純粋な成分は、必ずしも必ずしもライフサイクルと状態を持っている必要が容器アセンブリを意味するものではありません、そして自分自身のために、適切なガイドラインは、デカップリング用の結束のためのコンテナコンポーネントをコンポーネントを示すことです。

図4に示すように、パターンアセンブリロジックコンポーネント

CSS-で-jsから、このようなスタイルの成分としてのプロジェクトに便利なツールならば、おそらくどここの問題を置くスタイルを考えるので、次の処理が行われます。




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

この種のロジックはそれからより多くなります。

それの統一されたディレクトリの良い部品を標準化する方法はありますか？

答えははい、これは、分割コンポーネントがコンテナのコンポーネントまたはコンポーネントのスタイルとして識別される可能性が高い場合によく発達するので、この時間は、我々はそれらを分離していないために複数いくつかの方法に基づいていますが、すべてのコンポーネントされていますコンポーネントのディレクトリ、及び、モジュールに応じて分割は、全てのページがモジュールアセンブリによって結合され、最外層は、ページ・アセンブリは、コードの少量の単純かつ最もあるべきです。次のように：




├── 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

あなたが移行する場合たとえば、ユーザモジュールカタログ、プロフィール画像、情報カードやログインボックスのシナリオでは、私たちがそうするように、JS、個別に各コンポーネントのディレクトリの下にSCSSを画像を定義し、個々の成分は、その後、あなたは非常に簡単に移動することができます、ここで再びあなたは、機能を追加し、コンポーネントに直接追加するだけでなく、容易に拡張したい場合はLoginBoxは、その後LoginBox、下AreaListを、以下のこと。

最後に、ファイルに名前を付ける方法についてなど

これは、プロジェクトチームのどの条項によって異なりますが、一般的な原則があり、それはものの一種である場合のコンポーネントは、クラスとして見ることができますので、私の上の例を大文字にしなければならないので、アセンブリの名前として資本金は、比較的明確であるということです、より一般的な方法は、パス・ベースの命名と呼ばれている、そして、あなたが行うことができ、そのような内部の自宅/ index.jsでAreaListに名前を付けるように、ファイルのパス名に基づいています。




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

しかし、もはやLoginBoxで指名しないディレクトリがあれば、必要がある場合。




import AreaList from './AreaList';

概要

最後に、このようにサブモジュールに基づいて、開発者が自由に別々のコンポーネントに様々なフォルダに分散コンテナコンポーネントまたはコンポーネントを表示することができ、保護された標準化と柔軟性と言うことができます。

参照

HTTPS：//medium.com/@dan_abram ...
ます。https：//hackernoon.com/struct ...

出典：https://segmentfault.com/a/1190000018717822