2021-12-11FrontendReactTL;DRモダンなフレームワークに移行するなどと言うのは聞こえはいいが、ただ移行するだけじゃだめなのではという話。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などに移行したいとなったときにも発生しうる問題だと思います。Architecture」を読みました。その中で「フレームワークなんかと結婚するな」という話がありました。これはフレームワークのAPIをビジネスロジックに組み込むと、そのフレームワークをやめたくなったときに辛くなったりなどデメリットがあるよねという話が書いてあります。これは今回のケースも同じだと思います。react-routerを使うのではなく、一枚ラップしてから使うなどしたほうが、後々の変更に強くなります。フレームワークを乗り換えたり、新規に使うときなどはそのフレームワークを捨てるときのことまで考慮したほうがいいのではと思います。さいごにただ、こうは言っているものの自分の中で色々と疑問に思っていることもあります。以下のようなことです。ラップすると言ってもどこまでラップすればいいのだろうか?何でもかんでもラップするのか?この辺の線引きが難しい。ラップしたhookやコンポーネントのインターフェースがフレームワークに依存しすぎる形になってしまっては意味がないが、どうやったら使いやすく、変更に強いインターフェースになるのだろうか?まだまだわからないことだらけですが、今後自分で色々試す中でこの辺を鮮明にしていきたいなと思っています。Calendar2021の12/05の記事です。IPFactoryというサークルについてはこちらをご覧ください。明日はry0kvnの担当になります。