JavaScriptで条件分岐を書く際、ついif/else ifを連投しがちだけど、条件が増えるとコードが迷路のようになる。特にAPIレスポンスやユーザーロール判定で、静的な値ではない動的な変数を使いたい時に、switch文をどう柔軟に扱うかという問題に直面した話。
何が起きたか（課題）
- APIから返ってくるステータスコード（文字列）に応じて処理を分けたいが、
if文が長大化し、可読性が著しく低下した。 - ユーザー権限（'admin', 'editor', 'viewer'など）に応じて処理を変えるが、複数の軸（権限とアクション）で分岐させると、ネストが深くなりすぎてバグの温床になりそうだった。
-
switch文は固定値しか扱えないという誤解があり、動的な値をケースとして利用する方法がわからなかった。
どう解決したか（概要）
switch文の基本は厳格な比較（===）を使う点にある。まず、単一変数をケースとして利用する方法から試した。例えば、userRole変数の値を直接switchの評価式に渡し、対応する権限文字列をcaseに設定する。これにより、一連の処理をフラットに記述できた。
次に、複数条件を扱うためのアプローチを検討した。ネストされたswitchは避けるべきだと判断し、解決策として「ディスパッチキー」を作成する手法を採用した。これは、複数の変数を結合して一意のキー文字列（例: userType + '_' + action）を作り、その結合キーを単一のswitch文で判定する方法だ。これにより、複雑なロジックを単一のフラットな構造で管理できるようになった。
また、現場での安定稼働を担保するため、全てのcase末尾にbreak;を記述し、フォールスルーを防ぐことを徹底した。さらに、予期せぬ入力に対応するため、必ずdefaultケースを実装し、安全策を講じた。
効果（Before/After）
| 項目 | Before（if/else ifの連投、またはネスト） |
After（結合ディスパッチキーを用いたswitch） |
|---|---|---|
| コード構造 | 複雑なネスト、可読性低下 | フラット化、意図が明確に |
| メンテナンス性 | 条件追加のたびにコード全体の見直しが必要 | 新しいキー（case）を追加するだけで対応可能 |
| バグの温床 | フォールスルーや条件の見落としリスクが高い |
breakとdefaultにより堅牢性が向上 |
🚀 詳細な設定とコードはこちら
具体的なAPIステータス判定のコード例や、複合条件のディスパッチキー作成における完全な実装コード、そしてフォールスルーを防ぐためのbreak徹底の重要性については、元のブログで詳細に解説しています。