ログラスのReactの技術選定について🐳

ログラスのReactの技術選定について🐳 | 株式会社ログラス

こんにちはログラスのフロントエンドエンジニアの @Yuiiitoto です。「次世代型経営管理クラウド」のSaaSを開発しています。 今回Reactを使って開発しているログラスのフロントエンドがどういう技術を使っているのか、なぜそれを選んだかについて解説していきます。 Reactはライブラリの数が豊富な反面で群雄割拠している領域が多く、技術選定がとても大変です。同じ悩みを抱えるフロントエンドエンジニアの方に少しでも力になれればと思って記事にしました。 似たようなサービスの場合に特に参考にできる場合が多いと思うので、記事の前提としているサービスについて少し説明します。 ログラスはいわゆるtoBのSaaSの業務システムみたいな立ち位置です。ほぼ全てのページに認証が入り、画面の中の要素はtoCのサイトより多めです。Next.jsで構成されていて、SSGやSSRなどは使わずにデータはクライアントからフェッチしています。 ※ログラスは事業の予実を管理するサービスです。 今回、技術選定する領域は以下の3つです。 状態管理はSWRとContextを使った状態管理をしています。 APIからの値はSWRで管理していて、それ以外の値はContextを使って管理しています。 他に考えた選択肢では以下が挙げられます。 Redux + Redux Toolkit + redux-thunk(or saga) Redux + Redux Toolkit(非同期はTooklit内の機能のAsync Thunk) Redux + CustomHook アプリ内で状態管理したいものが大抵はAPIのデータ + SWRはそれに特化したライブラリだからです。大抵のものがSWRで管理しているので、それ以外のものをReduxで管理するのは学習コストとしても見合わないとしてContextを使うという判断をしました。 また、Reduxを使う場合はアプリ内で中央集権的に管理せざるをえなくなるので、マイクロフロントエンドやコンポーネントライブラリの切り出しが将来的に難しくなると判断しました。たとえばモーダル（ポップアップ）などの開閉状態をアプリ全体で保持したい場合、Reduxを使うと他のストアの情報と依存してしまいますが、Contextの場合は依存を最小限に抑えることが可能です。 SWRのメンテナンス性ですが、Vercel製で公式ドキュメント内でも使用が推奨されていることもあり、問題ないと判断しています（まだv0.xだけど）。 The team behind Next.js has created a React hook for data fetching called SWR.

www.wantedly.com