[react]構造

過去

反応を学習する過程で,フォルダ構造をそれほど考慮する必要はない.学習の過程や独自に作成した小さなプロジェクトは簡単なCRAで行い、大きな悩みもなくコンポーネントを作成しました.このようにしても,ほとんどの規模が小さいため,フォルダ構造を考慮したことがなく,必要性も見つからなかった.
しかし、おもちゃの計画が最初に行われる過程で、コンポーネントはますます多くなってきたので、次第に必要性を感じてきた.このプロジェクトを行う初期には、フロントには私一人しかいなかったので、毎日コンポーネントフォルダを作成し、コンポーネントファイルを粉砕しました.一定のルールがない場合,ページングコンポーネントファイルを大幅に作成し,ページ名でファイル名を生成した.その後、進行中にページングするコンポーネントをより小さく分割する必要がある場合に遭遇しました.これらのファイルをより小さな部分に分割し、componentフォルダに埋め込みます.1つのフォルダのファイルが10以上あるため、フォルダ構造を表示して意図を理解するのは難しいです.この时、メンテナンスの概念を全然知らないで、机能がよく现れさえすれば、私が作ったホームページはよく运転すればいいです.なぜコードの可読性などを思い浮かべるのでしょうか.このような気持ちはとても強いです.
その後、機能を修正したり、機能を追加したりするとき、コードにも簡単な変数名や関数名はありません.コードを理解するまで、私の混乱したフォルダ構造の中で何度も見てから、私の意図を理解することができます.そうなると、時間的な費用が非常に大きくなり、効率的な観点からもよくありません.必要性を少し感じましたが、この時点では私がまだ足りないためか、そのままスキップしてしまいました.ここではメンテナンスの概念を知らず、単純にコードを読む能力が低下するという意味です.
本当の問題は、もう一人のフロントの選手が入ってきたときからです.新しく加入したチームメンバーにコードとディレクトリ構造を説明する必要がありますが、説明しにくく、迷っています.自分のルールや会議が決まっていないので説明するのも容易ではなく、新しく加入したメンバーも理解するのに長い時間がかかります.これにより、メンテナンスの観点から、効率が低下し、時間コストがかかるだけです.やっとフォルダの構造を考えて、一つ一つ解決しました.pageを基準に、コンポーネントフォルダでページごとにフォルダを分離し、そのフォルダにコンポーネントを入れます.
階層構造

単一応答ファイル

複数の応答ファイル

反応ファイルから反応フォルダ

へ

*ページごとにコンポーネントを分離
ページごとに機能的に重なることが多いので、作業が便利で、修正や追加の際にもディレクトリ構造が見え、一目で把握できるようになり、機能の修正や追加が容易になります.

(私のやり直し設計基準と指導原則)

リアクターはライブラリなのでフレームのような一定のルールはなく、リアクターを使っている私たちは自由に入れて使えます.したがって,自由性は向上するが,自由性のみを向上させ,規定に従って一定の規則を制定しないとフォルダ構造が悪化する.
だから一定の指導方針を制定しなければならない.
現在、ワンストップ・プリロード中のほとんどのプロジェクト構造.

public
	data // mock data
	images // image file
src
	API
	components
		common // ui적으로나 공통적으로 쓰이는 컴포넌트
	pages // page별 큰 component
	styles // 공통 style이나 style들
	utils // 공통 로직 함수
	hooks 
	redux // actions, reducer, selector
	Router.js // routing을 하기 위한 파일
	config.js
	index.js