React hooksを使うことの一番大きなメリットはロジックとそこで使用するデータをUIから分離し、そして再利用できることです。
クラスコンポーネントでは、コンポーネントで発生する一連のイベントを複合的に扱うロジックは、いくつかのライフサイクルメソッドから呼び出されることになるため、つまりコールバックから断片的に呼び出されるため、コンポーネントと強く結びつくものでした。
「ライフサイクルコールバックのそれぞれから特定タイミングで呼び出されるコード断片の組み合わせとして表現されるロジック」そしてそのデータは、クラスコンポーネントに深く染み込み、編み込まれ、モジュールとして切り出すことはおろか、弁別することすら困難でした。一つのロジックならまだましで、2つ、3つのロジックを呼び出すとなると、地獄度は増しました。ロジックの分離のためにredux sagaのような鬼子も生まれました。(コールバックの集合をsagaではジェネレータベースのコルーチンで繋げていく)
そこで試行錯誤され編み出されたのは、HoC(高階コンポーネント)、render props、Function as childなどの荒業たちでした。それらはロジックをコンポーネントとして表現するものでした。
でも、コンポーネントで表現するべきなのは、UIパーツじゃなかったっけ。何でもかんでもコンポーネントにするのって、何かおかしいじゃん、
… (もっと読む)
クラスで書くのに比べて、書き易く、ロジックを共有し易く、テストし易いと思います。
書き易い
hooksになるとロジックは全て関数ローカルに収まりますので、処理の流れが追いやすく、変数に型が完璧にあたりますのでTypeScriptの恩恵をフルに受けられます。型が当たればどこでnullableな値が存在するのか分かったりして、コーディング中からケアレスミスは防げるようになります。
ロジックを共有し易い
hooksを使った自作hooks関数は簡単に書けますし、関数ですから別ファイルにかいて複数のコンポーネントで共有するのは簡単です。クラスの場合mixinとか継承を使ってロジックを共有していたかと思いますが、どちらもメンテナンス性が高くありません。どちらも前提とするコンテクストに依存していて、そのコンテクストを実装しているコンポーネントで再現しつつ個別の機能を実装するとなると、並大抵の労力ではありません。
テストしやすい
ロジックは全てシンプルな関数ですから、既に小さなコードに分割されていて、基本的には入力と出力を確認するだけで済みます。
これらの利点はプログラマーの脳内メモリをかなり節約できると考えています。初心者プログラマーは上級者に比べて作業が遅くなりがちですが、その原因はロジックの分割がうまくいかずに巨大なコンテクストを脳内メモリに載せがちというところにあったりします。または、コンテクストは大き
… (もっと読む)
DX＝開発者体験のためだと思っています。
どれだけ理論的にイケていても、DXを損なう言語やフレームワークは使われない傾向があります。それはVueの急上昇をとってみても言えることでしょう。
その点、Reactは「JSXが気持ち悪い」だとか「Reduxヨクワカラン」という批判に晒されていて、その中でReact hooksで状態管理ができることは既存のReactユーザーにとっては非常にDXを向上させる点で、ありがたかったんです。
より具体的には、複数のコンポーネントで状態を共有する必要がないなら、Reduxは冗長だし、Hooksを使えばクラスよりも状態管理ロジックを切り離しやすく、比較的短いコード量で実装できます。
またクラス使うメリットは、何万個とかのオーダーのインスタンスを作るときにはファクトリー関数より速いくらいしかないので、Reactにおいてはそこまでメリットはありません。
そう言った点で、関数コンポーネントで書きたいという強いユーザーの希望があり、その中で状態管理を実装しつつ、DXも高い形でのソリューションとしてHooksが捻り出されたというのが私の見解になります。
0 コメント:
コメントを投稿