Hooksは、classを記述せずにstateやその他のReactの機能を使えるようにしたもので、今は提案段階です。RFCはこちら
現在はReact v16.7.0-alphaで試せます。
Hooksの概要はこちら
https://qiita.com/tatane616/items/01d6358be5e4e4779232
IntroductionにHooks導入の動機が書いてあったので理解しようとしてみました。
ステートフルなロジックをコンポーネント間で再利用するのが難しい
Reactではストアに接続するなどと言った再利用可能なロジックを実装する方法がなく、render propsやHOCを使うしかなかった。ただ、これらはコンポーネントを再構築しなければならず面倒で、Reactはステートフルなロジックを再利用するより良い方法が必要。
Hooksを利用することで、コンポーネントからロジックを抽出して個別にテストしたら再利用が可能になる。Hooksではコンポーネント階層を変更せずにステートフルなロジックの再利用が可能。
複雑なコンポーネントになると理解が難しい
Reactを書いていると、最初はシンプルだったがステートフルなロジックと副作用で混乱状態になったコンポーネントをメンテナンスしていかなければならない時がある。
ライフサイクルメソッドには無関係のロジックが紛れ込んでいることがある。
例えば、componentDidMountとcomponentDidUpdateでデータをフェッチしてくるが、componentDidMountではイベントリスナーを設定する無関係なロジックが含まれていて、componentDidUpdateでそれを解除するなど。一緒に変化し、相互関連のコードが分割されて、無関係のコードが1つのメソッドに統合されてしまう。
これがバグなどを起こりやすくしてしまう。
多くの場合では、ステートフルなロジックが全体的に存在するせいでより小さなコンポーネントに分割しテストを行うことも難しい。これがReact本体とは別の状態管理ライブラリを使う理由の１つとなっている。
しかし、抽象度を高すぎると異なるファイル間のジャンプが発生しコンポーネントの再利用が難しくなる。
これを解決するために、Hooksではライフサイクルと言うよりは関連する動作部分に基づいて1つのコンポーネントをより小さな関数に分割していける。さらに、コンポーネントのローカルステートをReducerで管理することができる。
Classが人間とマシン両方を混乱させている
Reactのチームが観察したところ、Reactを学ぶ上で最大の障壁画Classの存在。JavaScriptのClassは他の言語とは動作が異なり、JavaScriptでどのように動作するかをしっかり理解しておく必要がある。イベントハンドラのバインドなどは冗長になる。
propsやトップダウンのデータフローなどは理解できるが、Classの理解が難しいらしい。
ReactでのClassと関数コンポーネントの区別やそれらを使うタイミングは、経験者でも意見が食い違うことがある。
また、AngularやGlimmerなどが示すように、ahead-of-time compilation（事前にコンパイルしておく）は将来性がある。Prepackを利用したコンポーネントの折りたたみなどは早い段階でいい結果が得られている。
しかし、Classはこれらの最適化を遅くしてしまう可能性があることがわかった。さらにClassには現在利用されているツールでの問題もあり、例えば圧縮が不十分でホットリロードが不安定になる。
このような問題を解決するために、HooksはReactの機能をClass無しで利用できるようにしていく。Reactは関数的なものに近く、Hooksは関数を取り入れるが、Reactの実用的な部分を犠牲にすることはない。
と言うことらしいです。
最後の、Classが学習コストをあげている点とパフォーマンスやツールのためにClassを排除しようとしている点は知らなかったです。