ただ移行するだけでいいのか？
TL;DR
モダンなフレームワークに移行するなどと言うのは聞こえはいいが、ただ移行するだけじゃだめなのではという話。
はじめに
最近、create-react-app(craco) + react-router割と大きめのシステムを移行する機会がありました。その中で感じたことや反省点などを書いていこうと思います。
モチベーション
まずなぜNext.jsに移行するのでしょうか?
- SSRやSSGなどの機能を自前で用意したくないし、メンテナンスしたくない
- Next.jsのpagesのようなファイルやディレクトリの構造がURLのパスと一致するようなルーティングシステムのほうがわかりやすい
- babelやWebpackの設定にあまり時間をかけたくない
- また、自分で簡単にカスタマイズしたいときにCRAに比べて簡単にできる
など、これ以外にも様々な理由があると思います。
個人的にはめんどくさいところや自前でメンテナンスするのはめんどくさいところはNext.jsに任せて、本当に作りたいところに集中したいというところが大きいです。
いざ移行
今回は私が実際に移行したケースを紹介します。
いっぺんに「全部Next.jsに移行できました！」とできればいいですが、実際問題そう簡単にはいきません。
今回は割と大きめのプロジェクトだったこともあり、ページ数も割とあり、queryパラメータを頻繁に書き換えるようなページではreact-routerのAPIがそのまま使われていると言う状況でした。
このような状況だったため以下のように段階を踏んで移行していくことにしました。
- react-routerを残したままNext.jsに移行する
- react-routerを消し、Next.jsのルーティングシステムに移行する
react-routerを残したままNext.jsに移行する
まずはNext.jsを導入し、既存の設定を壊さないように調整するところをやりました。
この段階ではルーティングはreact-routerを使って行う形にしていたため、pagesディレクトリ以下に[[...app]].tsxというファイルを作成し、ここにreact-routerのルーティングを記述するようにしました。
react-routerを消し、Next.jsのルーティングシステムに移行する
気合です。
ただ、queryパラメータの型周りがちょっとあれだったり、react-router側で簡単にできていたことができなかったりして少し辛かったところもありました。
型についてはpathpidaを使えば解消できたりするのかもしれませんが今回はそこまではやりませんでした。
移行してみて感じた課題感
これが今回一番書きたかったところです。
移行するときに一番大変だったのは、大量にあるreact-routerのLinkコンポーネントをNext.jsのLinkコンポーネントに変えるなどの、ただ単に書き換える系の作業が辛かったです。
これはNext.jsへの移行に限った話ではなく、Remixなどに移行したいとなったときにも発生しうる問題だと思います。
少し話が変わりますが、ちょっと前に「Clean Architecture」を読みました。その中で「フレームワークなんかと結婚するな」という話がありました。
これはフレームワークのAPIをビジネスロジックに組み込むと、そのフレームワークをやめたくなったときに辛くなったりなどデメリットがあるよねという話が書いてあります。
これは今回のケースも同じだと思います。直接react-routerを使うのではなく、一枚ラップしてから使うなどしたほうが、後々の変更に強くなります。
なので、フレームワークを乗り換えたり、新規に使うときなどはそのフレームワークを捨てるときのことまで考慮したほうがいいのではと思います。
さいごに
ただ、こうは言っているものの自分の中で色々と疑問に思っていることもあります。
例えば以下のようなことです。
- ラップすると言ってもどこまでラップすればいいのだろうか？何でもかんでもラップするのか？この辺の線引きが難しい。
- 例えばラップしたhookやコンポーネントのインターフェースがフレームワークに依存しすぎる形になってしまっては意味がないが、どうやったら使いやすく、変更に強いインターフェースになるのだろうか？
まだまだわからないことだらけですが、今後自分で色々試す中でこの辺を鮮明にしていきたいなと思っています。
この記事はIPFactory Advent Calendar2021の12/05の記事です。
IPFactoryというサークルについてはこちらをご覧ください。
明日はry0kvnの担当になります。