React/ReduxにSelectorを導入したら
品質が担保されるようになった話

入稿ツールってどんなもの？

松井真子氏：ヤフーの松井です。よろしくお願いします。まず簡単に自己紹介させてください。松井真子です。ヤフーに2018年に新卒入社しまして、ショッピングに配属されてからReactとReduxを使ってキャンペーンページ向けの入稿ツールとフロントの開発をしていました。

去年の9月くらいからはPayPayモールのAndroidアプリの開発をしています。UXに興味があり、サービスデザインの勉強をしており、今PayPayモールのAndroidアプリとかを通して新規機能の提案でサービス、デザインのチャレンジをしています。

趣味は釣りですが、外出自粛ということで今年に入ってから一切釣りに行っていないので、あつまれどうぶつの森で毎日釣りをいっぱいしています。

今日はReactとその仲間たちということで、入稿ツールのときのお話をしようかなと思っています。まず入稿ツールってどんなものなのかっていう簡単なイメージをお話しすると、WordPressをイメージしていただいたらよいかなと思っています。簡単に言うと入力されたデータをもとにHTMLを自動で生成するシステムの入力部分になります。

具体的な例としては画像モジュールで説明するんですけど、入稿ツール側でaltタグであったりとか、画像のURLを入力していただいて、フロント部分のシステムで入力されたデータをもとにイメージタグのHTMLを生成します。指定のURLをユーザーがアクセスしてきたときにはこのような画像のイメージが見えるかたちになっています。

入稿ツールを開発するときに困ったこと

今日お話しするのは入稿ツールを開発するときに困ったことです。そもそも自分が1年目で配属されてすぐだったということと、エンジニアの先輩であるチームメンバーもあまり開発経験がない方で、2人で開発経験が乏しい中、周りに相談しながらがんばっていました。

その中で困ったこととして、コンポーネント間の依存関係がすごく複雑になってしまっていたということと、バリデーションの実装が複雑になっていたこと。あとデータ構造が複雑でネストが深くなっていました。

このデータ構造が複雑かつネストが深いっていうのが、入力フォームのバリデーションの実装のところが原因に関係していました。入力フォームだったりモジュールのバリデーション結果だったり、エラーメッセージを持たせていたので、データベースの中に保存するべきではないデータも持っていたっていうのが原因になります。

今日お話しするのは簡単なLTということで、バリデーションの実装のお話をします。コンポーネント間の依存関係が複雑になってしまったことは、一から作り直しまして、Atomic Designを導入したことによって依存関係が一方向になることによって解消されました。

ということでバリデーションの実装のお話をしていきます。

バリデーションのタイミングが難しい

そもそもバリデーションが複雑になってしまった原因として大きく2つあって。1つ目がバリデーションのタイミングが難しかったということがありました。

タイミングとしてフォームが入力されるたびにバリデーションをかけたいということと、入稿ツールなのでデータベースからAPIで引っ張ってきていたデータも念のためバリデーションをかけたいということで、propsが変更されるタイミングでバリデーションをかけたいというのがありました。

実装方針としてActionやReducerの中ではロジックを持たせずにコンテナコンポーネントの中にロジックを閉じ込めるというような方針にしていたので、ライフサイクルメソッド、ComponentDidUpdateの中で実装をする必要がありました。

ComponentDidUpdateが外部メソッドを呼んでpropsに影響を与えるというようなことを許可していないので、バリデーションを切り出せず、同じようなバリデーションであってもひとつひとつのモジュールすべてで実装しないといけないかたちになってしまっていました。

もう1つの原因としてそもそもバリデーションが多いということがありました。入力フォーム単体であったり、複数の入力フォームを統括したり、複数のモジュールを統括してページ全体のバリデーションを持ったりという、バリデーションの種類が多いということ。

入稿ツールなのでどのモジュールが何個あるのかっていうのが固定ではなく、ビジネス要件も絡んでくるところなのですごく複雑です。バリデーションなのでしっかりしないといけないのですが、ひとつひとつに対してするってなるととても大変なことになっていました。

助けてくれたのがselector

そんなときに助けてくれたのがselectorで、Reduxのreselectというライブラリを使いました。これを使うとどうなるかと言うと、stateからpropsに渡すときに間にメソッドを挟んで関心のある値を返せるようになります。

なので、ComponentDidUpdateの中に書いていたバリデーションを切り出して、そのメソッドの返り値をpropsとして渡せるようになります。それまでは各フォームのバリデーション結果をStoreの中にひとつひとつ持たせていましたが、それを持たせずに値を直接propsに渡せるようになりました。

これによってバリデーションをComponentDidUpdatから切り出せたので、関心のあるバリデーションごとにしっかり切り出せるようになりコードがすっきりしました。責務分けをしっかりできたことによってテストが書きやすく、品質が担保されるようになりました。

バリデーションをComponentDidUpdateに書いていたときは値の変更箇所っていうのが複数存在してしまっていたのですが、selectorを挟んだことによってしっかりとどこでどの値が変化したかっていうのが追いやすくなりました。

selectorの機能を使うと、余計なデータを保持しなくてよい

今日のまとめです。selectorの機能を使うと、余計なデータを保持しなくてよくなりました。バリデーションを切り出せたのでコードもすっきりしましたし、テストもしやすくなりました。

今回自分がこれを実装したときがHooksの採用前っていうのと、関数コンポーネントではなくクラスコンポーネントを実装する必要があるライブラリがあったのでreselectを使ったんですけど。Redux Hooksのほうにも同じような機能が存在していました。

ただReduxの公式でもUseselectorとreselectを両方使う例もあったので、用途に合わせて使い分けをしていただいたらよいかなと思っています。発表は以上になります。ありがとうございました。