🎢

SPAをCRAからNextにスモールスタートで移行してみた!

2022/04/05に公開約3,300字

初めに

1月に転職してからHiTTOというAIチャットボットサービスを提供している会社で、フロントエンドエンジニアをやっています!
よかったら紹介動画を見てみてください。

HiTTO紹介動画

この記事はそんなHiTTOのチャット画面をCRAからNext.jsに移行したときに、どういうことを考えて移行を始めたのかや、その方針について書いていきたいと思っています!ほぼポエムです。
ちなみにまだリリースできていないので、投稿段階ではdraftになりますが、その辺は暖かく見守ってください!

移行の際に工夫したことや詰まった部分などのより詳細な話はまた今後別の記事にしようと思います!

動機

そもそもなんでCRA

CRAについて改めて書くことはしませんが、CRAのメリットとしては初期の開発開始スピードの速さと、babelやwebpack等のあれこれを書かなくて良くメンテが楽というところが挙げられるかと思います。

FEを始めて3年ですが、いまだにWebpackをまともに書ける自信がないです(小声)
そんなWebpackのスクリプト等を書かなくていいというだけでメリットを感じられる人も多いと思います。

CRAの不便さ

一方でCRAには不自由さがあり、スクリプトの一部を変えたい場合はreact-app-rewiredCRACOのようなミドルウェアを採用する必要があり、CRAがメンテしてくれるところから外れることになります。

また、2021年12月にv5がリリースされましたがそれ以前はメンテナンスが滞っており、今後の開発に若干不安な部分がありました。

移行を考え始めたきっかけとしては上記のCRAのデメリットの影響を少なくしたいという部分も多いですが、依存するライブラリ等が増えてきたときに、開発環境が重かったりビルドが遅かったりと開発体験も徐々に悪くなっていったのも一つの要員でした。

何故Next?

Nextに関してはより詳しく書かれている記事がいっぱいあるので詳細は省きます。

React界隈のフレームワークの中でもかなり盛り上がっており、メンテナンスもしっかりと行われていて、情報もかなり多かったので将来性や拡張性の面でとても安心できました。
CRAと同じく、ビルドスクリプトは書かなくても良い事やTypeScriptサポートが用意されている点はもちろんですが、必要に応じてWebpackのスクリプトをオーバーライドできる部分はとても大きいと思いました。

またパフォーマンス周りの最適化とかもNextの内部で実装してくれている事も一つの要因で、パフォーマンスが一つの大きな課題になっているので、その辺りの改善も期待できる点でした。

何よりNextを使ってみたい!というメンバー(というか自分)の意見もあり、移行を試してみようぜ!という流れになりました。

現状

簡単に現状の技術構成を記載します。
箇条書きのみであまり詳細は書かないので、FE仲間の記事をぜひご覧ください。

https://product-blog.hitto.co.jp/entry/2021/10/01/144308
  • create-react-app(react-scripts v5)
  • SPA
  • Atomic Design
  • react-router v6
  • storybook
  • IE対応

移行の方針

今回移行するにあたって、いくつか考慮事項があったので、先にメンバーと相談し方針を検討しました。

時間があまり取れないこと

現時点でとある大きなプロジェクトが動いており、チーム全体であまり余裕がない状態でした。
(こんな状況なのにNext移行に踏み切ったのは完全に個人的な好奇心が大きかったことを懺悔します)
一旦はログイン画面が動くことの確認を行い、あらためてチームとして時間をとり方針を決定することにしましたが、中々その時間すら取れず長い間やりたいことリストに眠っていました。

このままでは一生動かないだろうなと思いつつ、FEで集まった際に有識者も交えて色々と相談する機会があり、少し踏み込んだ話をしたところ、Nextに移行する上で本当はpagesの整理やESLint/prettierの設定、パフォーマンスの最適化等いろいろなことに手を出したいところではありますが、まずは管理画面よりもシンプルなチャット画面で、スモールスタートで移行してみて、そのあと徐々に最適化していこうという方針が決定しました。

SPAであること

本サービスは管理画面とチャット画面の2つのサービスから成り、それぞれにログイン画面があります。
ログイン画面→ログイン後の遷移は画面全体が変わりますが、ログイン後の画面内での遷移は、サイドバーやヘッダーが共通です。
これは画面の暗転を挟む事でユーザー体験を損なわないために行っていることで、そのためにSPAでコンテンツエリアのみを切り替えています。

NextといえばSSRやSGやISRによるパフォーマンスの向上やデータフェッチの最適化が売りで、個人的にも試してみたいと思っていましたが、まずは現状のSPAを維持したままあまり大きくは変えず、必要最低限の変更にとどめてとにかくNextで動く状態を作ってみようということになりました。

Nextはpages配下に置いたファイルがそのままルーティング対象になりますが、SPAを維持するためにsrc/pages/index.tsx内から、既存のreact-routerを使用してルーティングをしているコンポーネントを呼び出し、ルーティング自体は変えない方針で行くことにしました。

Dynamic RoutesやStatic HTML Export等のメリットは享受できませんが、スモールスタートでSPAのまま移行するには適した方法であり、開発体験の向上やWebpackの設定などのメリットはちゃんと受けられるので、とてもコスパの良い方針だったかと思います。

IEに対応すること

念願のIEのサポート終了も間近で、本サービスでもIEは基本非推奨になりましたが、IEを利用されるお客様はまだ一定数おり、いきなり使えなくなってしまってはいけないので、「あくまで多少のデザイン崩れやパフォーマンスの悪化はあるけど動きはする」という状態を維持する必要がありました。
そのため普段からライブラリの更新などには気を配っていましたが、Nextに移行する事でIEで動かなくなってしまっては本末転倒です。

Nextは設定要らずでレガシーブラウザでも動くとのことなので安心していましたが、しっかりと確認する必要がありました。

このIE対応でやっぱり沼にハマることをこの時点ではまだ知らなかった。。。

あと書き

ここまで読んでくださってありがとうございます!
実際に色々と苦労した記事はまた後日書こうと思いますが、一旦は力尽きたのでここまでにしたいと思います。

僕は活字が苦手なので、これくらい短い記事がちょうど良いのかなと思ったり、情報量少なすぎてどこに需要あんねん!って思ったり、まだまだ精進が必要だなと思いました。

Discussion

ログインするとコメントできます