「ReactではUIとロジックを分けて考えましょう」
学習を始めると、ほぼ確実に言われるこの言葉。
しかし、JavaScriptでDOM操作を学んできた人ほど、
「結局どこで何を書けばいいのか分からない」
「JSだけで書いていた頃と何が違うのか理解できない」
と感じるのではないでしょうか。
私自身、これまで肉体労働中心の仕事をしてきましたが、未経験からIT企業へ転職することになり、TypeScriptとReactの学習を始めました。
ToDoリストをDOM操作で実装していた頃は、UIもロジックもすべてJavaScriptに書くのが当たり前だと思っていました。
ですが、Reactの思想をDOM操作の経験と照らし合わせたとき、
「ああ、だから分けるのか」
と腑に落ちた瞬間がありました。
結論から言うと、ReactがUIとロジックを分けるのは、
状態の変化に強いアプリを作るためです。
なぜUIとロジックを分けないと辛くなるのか
DOM操作ではUIとロジックが密結合になりやすい
素のJavaScriptでToDoリストを作ると、以下のような流れになります。
- 配列を更新する
- DOMを削除する
- 新しくDOMを作成する
- ボタンにイベントを付ける
このとき、
「どこで何を表示しているのか」
「どこで状態を変更しているのか」
が同じファイル、同じ関数内に混在しがちです。
最初は動いていても、機能が増えるにつれて
修正するたびに全体を把握し直す必要が出てくる
という状態になります。
状態と表示が混ざるとバグの原因になる
UIとロジックが分かれていないと、
「表示は変わったのに、中身は変わっていない」
「配列は更新されたのに、画面は変わらない」
といったズレが起こります。
DOM操作でよくある、
- イベントが消える
- 古い値を参照してしまう
- どこで状態が変わったのか分からない
といった問題は、設計の段階で無理が出ているケースが多いです。
Reactは「UI＝状態の結果」と考える
Reactの基本思想
Reactでは、UIを次のように考えます。
UIは状態（state）の結果として自動的に決まるもの
つまり、
「この状態なら、このUIになる」
というルールを定義しておき、
実際の表示切り替えはReactに任せます。
これにより、開発者は
「今どう表示するか」ではなく「状態をどう変えるか」
に集中できるようになります。
DOM全削除＋再描画を安全に行っている
以前作成したToDoリストでは、
document.querySelectorAll("p").forEach((p) => p.remove());
というように、一度DOMをすべて削除してから作り直していました。
Reactも内部的には、
「前のUIをもとに差分を計算して再描画する」
という処理を行っています。
違いは、
- DOM操作を自分で書かなくていい
- 状態とUIの対応関係が明確
という点です。
UIとロジックを分けると何が変わるのか
ロジックは「状態をどう変えるか」だけを書く
Reactでは、ロジックは次のような責務に集中します。
- データを追加・削除する
- true / false を切り替える
- APIの結果を受け取る
表示の切り替えは、
「この状態ならこのUI」
という宣言的な書き方に任せます。
そのため、コードを読んだときに
「何が起きているか」 が追いやすくなります。
UIは「見た目の定義」に専念できる
UI側では、
- 配列をmapで回す
- 条件によって表示を変える
といった処理だけを書きます。
イベント処理の中でDOMを探し回る必要がなくなり、
「このコンポーネントは何を表示しているのか」
が一目で分かるようになります。
DOM操作経験者ほどReactの考え方は理解しやすい
一見すると、ReactはDOM操作を隠していて難しそうに見えます。
しかし実際は、DOM操作で苦労してきたポイントを、
先回りして解決してくれている仕組み です。
- 再レンダリングでイベントが消える問題
- UIとデータのズレ
- 状態管理の複雑化
これらを、
「UIとロジックを分ける」
という設計でまとめて解決しています。
まとめ
ReactがUIとロジックを分けて考える理由は、
コードを綺麗に見せるためではありません。
- 状態管理をシンプルにする
- UIの再描画を安全に行う
- 変更に強いアプリを作る
これらを実現するための考え方です。
DOM操作でToDoリストを作った経験がある人ほど、
Reactの思想は必ず腑に落ちます。
コメント