😗

個人開発でのフロント技術選定をReactにした話

に公開
React
プログラミング
frontend
フレームワーク
tech

なぜ僕は生JavaScriptではなくReactを選んだのか

1.スクールのメンターさんにはJavaScriptを勧められていた

当初メンターさんは「JavaScriptでいいんじゃないか？」と言いました。その理由は開発期間が短く、Reactを一から学習して取り入れるのはコストが高いということからの判断でした。
僕がReactを使用したいといったと、メンターさんは何故そうしたいのかを問いましたが、その時の僕は「なんとなくみんな使ってるから」「とりあえず今一番フロントで使われているReactに触れてみたい」という何故このサービスにReactが必要なのかの部分を話せずぼんやりとした回答になってしまったため、このサービスにはReactを使用する価値があるのか、そしてなぜ最終的にReactに決めたのかという部分をお話していきます。

2. 個人開発で作成するサービスの要件（Swipe型意思決定アプリ）

「何となく開いたら、スワイプするだけで“やること・行く場所・観たい作品”が決まるWebアプリ」

主な機能

  • ジャンルごとにカードをスワイプで仕分け（YES/NO・保存）
  • 保存リスト（マイリスト/履歴）があり、そこからまた操作できる
  • 保存数の上限や「また今度」などのステータス移動
  • 各カードは画像・説明・外部リンク付き
  • 外部API（Google Place、TMDB）からデータを取得
  • Google認証でログイン

とにかく「状態変化（保存・削除・移動・UI更新）が多いサービス」

3. なぜReactじゃなきゃ厳しいのか

理由1：状態管理が多すぎる

  • スワイプした瞬間にカードが消える
  • 保存リストに即追加/削除/移動
  • 複数の画面（カード一覧・履歴・保存リスト）にまたがって「同じデータの状態」をUIに即反映

理由2：UIと状態の同期が“自動”じゃないとバグる

  • 保存数上限、状態切り替え、リストの入れ替え…
  • 状態ごとに「どのUIをどう変えるか？」手動でやるのは無理ゲー
  • Reactなら useState で「データを変えたらUIが自動で最新化」

理由3：部品（カード・ボタン）の再利用が超重要

  • 何度も使うカードや保存ボタン、ナビなど
  • コピペで作ると「一箇所修正したら全部直す」地獄に
  • → Reactのコンポーネント設計が圧倒的に便利

4. 生JavaScriptでやろうとすると何が起きるか

  • 状態（データ）管理を自分で配列・変数で全部持つ
    • どのカードがどのリストにいるか、どのステータスか…を全部管理
    • UIとズレると「画面にはあるのにデータから消えてる」「リストを移動したのに別リストで消えてない」など、バグ量産
  • UI更新も全部手作業
    • 例えばスワイプ時に
      • 配列から該当カード削除
      • 画面の該当divやliも消す
      • 保存リスト・履歴画面も手動で更新
    • 一つでも抜けると「幽霊カード」「二重表示」「消えない」などが発生
  • 複雑な画面遷移やリストの絞り込み・並び替えが増えるたびにカオス化
  • イベント管理（onClickなど）もグローバルになり、どこを直したらどこが壊れるかわからなくなる
  • バグを潰すたびに新しいバグが生まれる負のループへ…

5. まとめ：だからReact一択だった

  • Reactは「状態管理」と「UI自動同期」が標準装備
  • 「状態を変えればUIが必ず正しく反映される」のでバグが激減し、追加機能や修正にも強い
  • 実際の現場レベルのWebアプリは、生JSだと「バグ量産」か「死ぬほど管理が大変」
  • だから本気でアプリを運用したいならReactは“贅沢”じゃなく“必須”の選択だと実感！

Discussion