よいDXに向けてRecomposeのHOCをReact Hooksに置き換える
よいDXに向けてRecomposeのHOCをReact Hooksに置き換える
どうもTAKUYAです。InkdropというMarkdownノートアプリを1人で作っています。そのモバイル版はReact Nativeで組まれています。最近コードベースをリファクタリングして、RecomposeからReact Hooksに乗り換えました。本稿ではその作業の際に発見したコツなどをシェアしたいと思います。
HOC多用はメンテナンス性が低くなる
RecomposeとはHOC(Higher-order components)で効率よくStateless functional componentsベースのReactアプリを組むための便利関数ライブラリです。作者はAndrew Clarkです。例えるなら、React版Lodashみたいな感じです。このライブラリの開発は2018年12月4日を最後に止まっています。なぜなら彼がReactのチームに参加したからです。そしてReact HooksがReact v16.8にて導入されました。
彼らが言うように、React Hooksを使うためにわざわざ夜を徹して既存コードを書き直す必要はありません。でも僕はやりました。自分のコンポーネント群を書き直した理由はいくつかあります。RecomposeはHOCベースでアプリを書くためのライブラリです。HOCの関数群は再利用性が高いため、同じロジックを書く手間を大きく省いてくれます。一方で、このRecomposeとHOCを採用することによるデメリットもあることが分かりました：
1. スタティックタイピングが上手く動かない
僕はプロジェクトのタイプチェックにFlowを使っています。RecomposeのFlow定義は次の例のように、FlowのType Inference機能に強く依存しています：
import { compose, withHandlers, pure, type HOC } from 'recompose'
type Props = {}const enhance: HOC<*, Props> = compose(
connect(({ editingNote, editor, session }) => ({
editingNote,
readOnly: editor.readOnly || session.isReadOnly
})),
pure,
withKeyboard(),
withHandlers({
handleTitleFocus: _props => () => {}
})
)const Editor = enhance(props => {
// ...
})
これだとなぜか props が頻繁に any として解決されてしまって、コンポーネント中のタイプチェックが上手く働かない事があって困っていました。Flowは僕が間違ったプロパティを参照しようとしていても教えてくれません。これでは意味がない。さらに、 props の中身がコードを見ただけではすぐに分からないという問題もあります。HOCの入れ子が増えれば増えるほど、この問題は深刻化します。
2. React Developer Toolsでデバッグしづらい
上記画像をご覧の通り、たくさんのpure(withHandlers(Component)) のようなHOCが積み重なっており、実際のコンポーネント構造が全く把握できません。そのせいでReact Developer Toolsの実用性がほとんど失われてしまっています。
3. fbjsに依存している
Recomposeはfbjsに依存しています — — これはFacebookが内部で使っている便利ライブラリですが、今は廃止されてメンテされていません。このライブラリが更に古いモジュールに依存しているため、使うだけで不必要にプロジェクトは肥大化し脆弱になってしまします。なので、僕はいつもfbjsが依存ツリーに含まれていないか確認しては除去するように努めています。
