JavaScriptライブラリ「React」導入した結果と気付き

お疲れ様です。
メディアクリエイション事業部 開発課のリヌスです。

5年ほどWEB開発に携わり、現在はフルスタックエンジニアとして業務に従事しています。

フルスクラッチのプロジェクトを社内外問わずに何件も経験し、最近は現職社員による口コミメディア「VOICE」の開発を主に担当しています。

より「VOiCE」について詳しく知りたい方はこちら！
現職社員の声で会社選び

▲　桜を背景に1枚

最近とあるプロジェクトで、JavaScriptライブラリ「React」を初めて導入することになり、導入前に考えていたことと導入後に感じたことに対してブログで共有できればと思います。

内容の特性上、記事にWEB開発用語が多く含まれるため、非エンジニアの方にとっては少し難しく感じるかもしれませんが、初級エンジニアや開発経験者にとってReactの導入する際の参考になれば嬉しいです。

今回、Reactを導入しようと思った理由は次の二点です。

一点目は、フロントエンドのデベロッパーエクスペリエンス（DX）とJavaScriptフレームワークの安定性においてReactが優秀だと考えたためです。
そのため、Reactの導入を強く主張しました。

二点目は、担当していたプロジェクトで入力フォームのUIを設計するにあたり、一つの画面の中で複数のモーダルを表示させる必要が出てきたためです。
他にも、そのページ内でそれぞれの入力フィールドやコンポネントのステートを管理する必要がありました。
それらをふまえたページの実装を簡単に行う方法として、Reactが最適だと考えました。

Reactとは？

Reactを簡単に紹介するとフロントエンド部分をコンポネント化させ、ステート管理や部分的なレンダリングを簡単にするJavaScriptのライブラリです。

JSX（JavaScript XML）と呼ばれるシンタックス（構文）で作りますが、JS（JavaScript）で出力するHTMLのような形で、直接JSXにJSを埋め込むことも可能です。

つまり、ベタJavaScriptで頻繁に必要とされる処理や整理を迅速に行い、かつ開発者にとっては開発業務を楽にしてくれるツールなのです。

React実装における想定課題

今回の実装において、いくつか想定課題があったので紹介します。

フロントエンドバリデーション

伝統的なMPAのフォームの場合は、入力した後に「送信」を行ってから、一回サーバーにリクエストしてバリデーション処理を行います。
そのため、ユーザーにとって入力バリデーションを待つ時間が長く感じることがあります。

JSでバリデーションをチェックすれば処理時間が短くなり、ユーザーのストレスも減るため、React用の強いライブラリを導入したかったです。

画像選択モーダル実装

画像選択肢モーダルを出して、選択中の画像のプレビューサムネを出す部分がありました。

かつ、何か所でも使われるため、Reactのコンポネント化してコードを再利用できる状態にしたかったです。

追加・削除できる入力フィールド

MPAでフィールドの追加・削除をクライアント側で行う際は基本的にJavaScriptを使いますが、過去の実装経験からこの対応が面倒なことを理解しています……。

Reactのステートにより、この動作の実装がもう少し楽になると思いました。
かつ、これはDOM操作に該当し、Reactが「仮想DOM」を操作することでベタJSの処理よりも早くリレンダーが行える点もReactのメリットの一つです。

使いやすいdatepickerの導入

JS用のDatepickerライブラリは非常に多く、internationalizationがダメだったり、使いづらかったりすることが多いです。
しかし、React用のライブラリで使いやすいものがあることを知り、それで実装できれば良いと思いました。

実装してみた結果・感じたこと

想定した課題に対して、Reactの技術により実装対応が非常に楽になったと感じました。

React使うことで、ベタJSで膨大に必要なコードが短くなり、コンポネント化することでコードも少し整理しやすい状態になりました。（当然改善の余地はあります）

React用の強力なライブラリなどが数多く備えることができ、主なライブラリとしてフォーム作成やバリデーション処理などのフォーム周りすべてを簡単にしてくれる「React Hook Form」も導入しました。

実装して感じたメリットは以下の通りです。
・ステート管理やフロント側の動的部分の実装自体は、Reactの基礎概念さえ理解すればJSで面倒だった部分が簡単に感じた。

・Reactのコンポーネント化したらコードも整理しやすい。

・今回作成した「画像選択モーダル」は複数の場所で使う必要があるため、再利用できるように対応した。
画像サムネをプレビューするところ・画像モーダルを開くボタン、モーダル内の選択中画像の表示、保存ロジックのJS、すべてがコンポネントで網羅できるため、再利用性高く作成できました。
React以外ではできないというわけではないが、UIで考えるコンポネントのデザインや動作をすべてまとめて再利用する点では本当に使いやすいと思いました。

・業界スタンダードのReactなので、安定しているライブラリの選択肢が豊富。
なぜ業界スタンダードだと言えるのかというと、まずフロントエンドフレームワークではReactの使用率が圧倒的に多いです。
他のフロントエンドフレームワークの合計を出してもReactが使わられるサイトの方が多くなっています。

参考：JavaScript開発者向けサーベイのフロントエンドフレームワーク使用率
（https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/）

Stack Overflowのタグトレンドも確認すれば同じ傾向が見られます。
参考：Stack Overflow
（https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue.js%2Cangular%2Csvelte%2Cangularjs%2Cvuejs3）

次に、なぜReactの使用率がそこまですごいと言えるのが、Reactの保守性・安定性にあると言えます。

Facebook社によってFacebookで使うためにReactは開発されました。

そのため、Facebookで利用されている限り、Reactが保守されます。

反省点と考慮点

全体的には良い対応ができたのではないかと考えています。

ただし、MPAにReactを埋め込んだ際の課題解決方法に関しては、他にも選択肢がないか少し疑問に思っている状況です。

例えば、今回は環境構築や最終的なビルドをするためにそれなりに時間が必要でしたが、Reactを完全に分離したもので疑似バックエンドを使えたら、導入コストを減らして最終的にCDNなどからMPAに読み込ませるだけの方法も考えられます。

とはいえ、その場合もプロジェクトの状況によっては他の課題も発生しそうな気もします。

最後に

ほとんどの想定課題は問題少なく対応できましたので、今回の技術選定はReactでよかったのではないかと考えています。

これからもReact実装をしていけたらと思います。

ベタJSで書くよりは非常に心地よく、MPAの埋め込みでも、一回さえ環境構築の大変なところを乗り越えれば、その後のReactスケールアップの際は同様の対応が当然不要となります。

プロジェクトによって考慮は必要ですが、ぜひZenkenでも積極的にどんどん新しい技術を試して導入していきたいです。