概要

ProductTableコンポーネントにおいて、任意の在庫商品の削除確認モーダルを閉じるとフォーカスがリセットされるバグが発生するため、その解消に対応します。

※ PR = Pull requestの略。

変更内容

• useEffectを使用してisModalOpenの状態がfalseに変化することをトリガーにして、モーダルが開く直前に保持していた削除ボタンに再びフォーカスが当たるように修正を施しました。

確認事項（動作確認）

PRのコードレビューの手順（GitHub Flow） の通り作業し、PRのレビューをする中で以下の動作確認を実施します。

• Tabキーを打ってフォーカスを任意の削除ボタンに移動させEnterキーを押下した上で、現れたモーダルの閉じるボタンにフォーカスが当たっている状態でEnterキーを押下しても、モーダルが閉じた時に直前までフォーカスが当たっていた削除ボタンに再びフォーカスが当たること。

• Tabキーを打ってフォーカスを任意の削除ボタンに移動させEnterキーを押下した上で、現れたモーダルのCancelボタンにフォーカスが当たっている状態でEnterキーを押下しても、モーダルが閉じた時に直前までフォーカスが当たっていた削除ボタンに再びフォーカスが当たること。

• Tabキーを打ってフォーカスを任意の削除ボタンに移動させEnterキーを押下した上で、現れたモーダルのDeleteボタンにフォーカスが当たっている状態でEnterキーを押下すると、モーダルが閉じて対象の在庫商品が削除された後、直前までフォーカスが当たっていた削除ボタンより一つ前の削除ボタンにフォーカスが当たること。

• 任意の在庫商品の削除ボタンをマウスでクリックし、現れたモーダルの閉じるボタンをマウスでクリックしても、モーダルが閉じた時に直前にマウスでクリックした削除ボタンにフォーカスが当たること。

• 任意の在庫商品の削除ボタンをマウスでクリックし、現れたモーダルのCancelボタンをマウスでクリックしても、モーダルが閉じた時に直前にマウスでクリックした削除ボタンにフォーカスが当たること。

• 任意の在庫商品の削除ボタンをマウスでクリックし、現れたモーダルの外側の背景をマウスでクリックしても、モーダルが閉じた時に直前にマウスでクリックした削除ボタンにフォーカスが当たること。

• 任意の在庫商品の削除ボタンをマウスでクリックし、現れたモーダルのDeleteボタンをマウスでクリックしても、在庫商品が削除されモーダルが閉じた時に直前にマウスでクリックした削除ボタンより一つ前の削除ボタンにフォーカスが当たること。

PRのコードレビューの手順（GitHub Flow）

1. プロジェクトのルートに移動する。

   cd react-practice
   

2. 対象のPRを取得する。

   git fetch origin pull/2/head:fix/focus
   

3. PRのブランチに移動する。

   git switch fix/focus
   

4. 動作確認をしながらPRのコードレビューを実施し、必要に応じてコメントを追記する。

   • 実際の開発現場では、GitHub上で対象のPRのページの「Files changed」タブでレビューを書き込み、PRの作成者に共有することが一般的ですが、任意で大丈夫です。ローカルでコメントを追記しても大丈夫です。

   • GitHub上でレビューを追記する場合は、Files changed」タブに移動して任意のファイルを選択し、ソースコード内にマウスのポインタをホバリングをすると青色のプラスボタン➕が現れ、好きな箇所でレビューを書き込むことができます。

   • すべてのファイルのレビューが完了したら、右上のSubmit reviewを押下します。

   • ※ なお、Files changedタブで追記したコメントはローカルでgit pullをしても現れませんので、勉強の理解のために、追記したコメントを残したいのであれば、ローカルでコメントを追記することをお勧めします。

5. コメントの追記によって変更されたファイル全てを、コミット対象にする。

   git add .
   

6. PRに対して施した変更をコミットする。

   git commit -m '任意のコメント'
   

7. 追記したレビューコメントのコミットをPRに反映させるために、PRのフォーク元のリモートリポジトリを登録する。

   git remote add ken-script [email protected]:ken-script/react-practice.git
   

8. 以下の通りに、コミットをリモートのPRにプッシュする。すると、自動でPRが更新され、ローカルで作ったコミットがPRに反映されるはず。

   git push -u ken-script fix/focus
   

   ※ 上記のように、push先はoriginではなく、自分のアプリをフォークしたPRの作成者のリポジトリにpushすることで、自分が追記したコメントのコミットがPRに反映されます。originですとPRが勝手にマージされてレビューコメントの追記が出来なくなります。

9. Github上にて対象のPRをマージします。

   ローカルではなくGitHub上で先にマージを実行することで、GitHub実績バッジ(Achievements)が付与されるので大変お勧めです。マージの手順は以下の通りです。

   1. このPRのページ下部に緑色のチェックマーク✅で「No conflicts with base branch」と表示されていればそのままマージしてもコンフリクトが起きませんので次のステップに進みます。

   2. 逆に、灰色の注意マーク⚠️でThis branch has conflicts that must be resolvedが表示されている場合、マージするとコンフリクが起きるため、右横の「Resolve conflicts」ボタンをクリックして以下の手順で解消しましょう。なければこのステップをスキップします。

      • コンフリクトが起こり得るファイルのリストが一覧されるので一つ一つ確認します。

      • ファイル内で「Accept current change、Accept incoming change、Accept both changes」のどれかを選んで変更を選択します。

      • ファイル内のすべてコンフリクトを解消できたら右上のMark as resolveを押下します。するとそのファイルに緑色のチェックマーク✅が付きます。

      • そして、全てのファイルのコンフリクトが解消されると、右上に「Commit merged」ボタンが現れたら押下します。

      • PRのページに戻り、緑色のチェックマーク✅で「No conflicts with base branch」になればOK。

   3. コンフリクトがない状態で「Merge pull request」ボタンを押下します。すると、マージのためのコミットメッセージを記述するフォームが表示されます。（デフォルトのコミットメッセージのままでも大丈夫）

   4. そして、「Confirm merge」ボタンを押下してマージコミットを確定させます。すると「Pull request successfully merged and closed」が表示されて無事にマージが完了します。PRのタイトルの左横に紫色で「Merged」のマークに変わります。

   5. PRのマージ完了後、自分のProfileに実績バッジ(Achievements)が付与されるはずです。表示されない場合は、Settings > Public profile > Profile settings にアクセスし、以下のように「Show Achievements on my profile」のチェックがオンになっているかどうかを確認しましょう。

      • Show Achievements on my profile
   • ※ それでも実績バッジが表示されない場合は、実績バッジが付与される条件を満たしていない可能性があります。興味があればお調べすると良いでしょう。

10. リモートでPRのマージ先のブランチ(main)の最新をローカルに取得して反映させます。

    git switch main
    git pull origin main
    

    ※ `git pull = git fetch + git merge

11. mainブランチの最新の状態を他のブランチに取り込ませます。

    git switch fix/focus
    git merge main
    

12. mainの最新の状態を取り込んだブランチを自分のリモートリポジトリ(origin)にプッシュします。するとGitHub上のbranchesでfix/focusブランチが追加されます。

    git push -u origin fix/focus
    

• 以上で、PRのコードレビューが完了です。お疲れ、おつちか姫。

• 📝　ポイントとして、PRはGitHub上で先にマージすべし。ローカルでは、git pullでmainブランチを最新にし、それぞれの作業ブランチでmainの最新状態をマージします（git merge main）。

• なお、この手順はGitHub Flowに沿ってまとめました。

• 以上です。

その他

• このアプリはリファクタリングの余地があります。

• FilterableProductTableコンポーネントが、他のコンポーネントで使用するイベントハンドラーのほとんどを抱えています。言い換えて、FilterableProductTableが全ての責務を抱えています。つまり、責務の分離をまだ果たしていない状態です。

• それらのイベントハンドラーはFilterableProductTableコンポーネントではなく、他のコンポーネントで使用されるため、直接それらのコンポーネント、または、その親コンポーネントに持つべきです。

• 例えば、モーダルに関するイベントハンドラー（handleCancelButton、handleDeleteButton等）は、Product tableの範囲内で使用されますが、他のコンポーネント（SearchBar.jsxやAddProductForm.jsx等）では使用されないです。

• また、仮にチーム開発でそれぞれのメンバーがそれぞれの作業ブランチで作っているコンポーネントのイベントハンドラーすべてを、FilterableProductTable.jsxファイルで実装すると、同一のファイル（FilterableProductTable.jsx）を編集しているため、mainブランチにマージした時にコンフリクトが発生する可能性が極めて高いです。（コンフリクトを回避するにはなるべく別々のファイルで開発する事が好ましいです。）

• 現状の実装では、それぞれのコンポーネントが使用するイベントハンドラーが、propsのバケツリレーを通じてFilterableProductTableコンポーネントから取得されているためFilterableProductTableコンポーネントに密結合になっている状態です。

• 言い換えると、FilterableProductTableに依存しないと生きていけない状態です。そのため、コンポーネントが独立した時にイベントハンドラーがないため機能せず、再利用が難しいです。コンポーネントの概念としては、独立してもちゃんと機能することが大事です。

• 他のコントリビュータ（リスナー）さんが作ったImportProductコンポーネントに目を通すと、そのコンポーネントで使用されるイベントハンドラー（handleFileChange）は、FilterableProductTableコンポーネントではなく、そのImportProductコンポーネントの範囲内で実装されています。そのおかげで、後からこのImportProductコンポーネントをimportで追加しても修正箇所が少なく、また、別のファイルで機能するように実装されているため、mainブランチにマージしてもコンフリクトが発生する確率が低いです。

• Atomic Design に沿って改善するのであれば、FilterableProductTable内で実装されているイベントハンドラーのほとんどを、それらが使用されるコンポーネント、または、その親コンポーネントに移すことを推奨します。そして、FilterableProductTableはLayoutという役割に留めることです。

• そうすることで、品質の高いコードに生まれ変われますし、コンポーネントの追加と取り外しが簡単になるため、今後の改修が楽になります。

• 新しく別のアプリを作ったり、新しい技術の勉強に進む事はとてもいい事ですし、楽しいことですが、上記にあげた問題点の解決に挑戦し取り組むことで、チーム開発の現場で通じる真の実力が身に付きますし、飛躍的に成長するチャンスの可能性があります。