Reactフォルダの構造と設計に対する考え方


なぜreactフォルダ構造を考慮するのですか?


Reactによるフロントエンド開発では,フォルダ構造を考慮することが多い.しかし、有名な開発者のフォルダ構造から見ると、彼らの構造はそれぞれ異なるので、reactを使用する開発では、選択しなければならない道はありません.
react開発チームが作成した正式なファイルでも、フォルダにファイルを整理する方法をお勧めしていません.
< ファイル構造の応答式ドキュメント >
これは私にとって「それらは実は重要ではありませんか?」言っているように聞こえる.実際、どのようなフォルダ構造を採用してもReactのパフォーマンスには影響しません.
では、私たちは自分の好みでフォルダ構造を設計してもいいですか?半分が間違っていると思います.「個人種目では、私の好みは100%で、私が理解して理解できれば、問題ありません.」「これはちょっと変な…?」このような考えがない場合、私にとって快適な方法だけが最も効率的な方法です.
しかし、個人ではないチームプロジェクトではどうなるのでしょうか.チームプロジェクトで一度協力したことがある人も同感です.定数や関数名を定義するスタイル、使用する論理など同じ部分よりも、他の部分のほうが、私のような開発者はこの世にいません.そのため、個人的なプロジェクトのようにフォルダ構造を勝手に設計できない場合が多い.私のフォルダ構造はチームの性質とプロジェクトの目的に基づいて、効率と生産性を妨げる可能性があるからです.
コラボレーションを行う理由の1つは、大規模なプロジェクトの目的を達成し、効率と生産性を最大限に向上させるためです.根拠もなく100%好みのフォルダ構造だけを入れるのも危険ですが、迷わず有名なフォルダ構造を導入するのも問題になります.
したがって、「reactでどのフォルダ構造を使用するのが一番いいか」ではなく、フォルダ構造のタイプとメリットとデメリット、およびどのような場合に使用するかに重点を置きます.

ファイルタイプ別に分類


緒論はもう長いので、Reactのフォルダ構造タイプに直接入りましょう.まず、書類の種類によって分類して、その中で最も有名なのは陶磁器の設計です.
のatomic設計は,ページの構成部分を原子単位に分けることから考える.上の写真から分かるように、ボタンや入力、画像などの最小単位をボタンや文字枠などを含むタイトルやナビゲーションバーに編成します.その後、再び関連付けられたものをより大きな単位で組み合わせたのが原子設計です.
では、フォルダ構造はどうなりますか?原子設計の単位で構成すればよい.
src
 └ components
   	   ├ pages
       ├ templates
       └ UI 
          ├ atom
          ├ molecules
          └ organism
長所
  • ユニットは組み合わせが自由で、メンテナンスが容易です.
  • の大規模なプロジェクトで構成が容易です.
  • 短所
  • 5段階の親子関係なので、不要な道具訓練が起こりやすい.
  • の規模の小さいプロジェクトでは、効率が高くない可能性があります.
  • n/a.結論
  • の規模の大きいプロジェクト、あるいは将来拡張可能なプロジェクトであれば、設計方式を採用することができます.
  • 欠点を改善するには、
  • Reduxなどのグローバルステータス管理ツールを使用する必要があります.
  • ファイルの機能またはルーティングに基づいて


    一番試しやすい方法かもしれません.ファイルがどのような機能を担当するかによって、フォルダごとに分類されます.あるいは、特定のルーティングに属する機能のみをバンドルすることができる.
    一般的に、ウェブページは「アパレルショッピングセンター」のように大きなテーマを持ち、サブテーマによって異なるルートを持つ経路に分化する.
    たとえば、映画リスト、映画コメントバー、マネージャページからなるページがあるとします.3つの機能は、「/movie-list」、「/movie-comment」、および「/admin」のルーティングでそれぞれレンダリングされます.したがって、フォルダ構造は次のようになります.
    src
     ├ list 
     │  └ info 
     ├ comment  	 
     │     └ form
     └ admin      
    長所
  • でこのルーティングのフォルダで作業するだけなので、非常に直感的です.
  • 不要な親子関係が最小化されます.
  • 短所
  • を再利用する可能性は低下する可能性があります.
  • 反応チームが特定の設計方法を推薦しないのは、実際にある方法を堅持する人が少ないからだ.いろいろな方法の長所と短所を採用し、プロジェクトのスタイルに応じて拡張と変更を行うことがもっと重要だと思います.最後にReactionドッグチームの短いコメントです.
    プロジェクトが拡大するにつれて、実際には前述の方法を混合して使用します.そのため、最初から「正しい」方法を選ぶことは重要ではありません.

    参考資料

  • ファイル構造の応答式ドキュメント - React team
  • げんしせっけい - Brad Frost
  • アプリケーション内のフォルダ構造を反映 - Katia Wheeler