はじめに

useState は書ける。でもレビューで「なぜこのstateはここにある？」と聞かれると、うまく言葉にできない。自分はstate管理をライブラリの話として捉えがちでしたが、調べてみると、その前に「何を覚えるか」「誰が持つか」「どこが正本か」を決める必要があると分かりました。この記事では、その判断をReactの小さな例で整理します。

TL;DR

計算できる値はstateにせず、保存する情報を最小限にする
共有するstateは、それを使うコンポーネントの最も近い共通親に置く
React内のownerと、Server / URLなど「データの正本」は分けて考える

1. state管理は「ライブラリ選定」の前にある

ReduxやZustandを選ぶ前に、そもそもstateが何なのかを整理した方が話が早そうです。Reactの公式ドキュメントでは、stateはコンポーネントの「memory」として説明されています。

たとえばカウンターなら、画面が次のレンダーでも覚えておく必要があるのは count です。

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  )
}

ここで大事なのは、count が単なる変数ではなく、「このUIが次のレンダーでも覚えておきたい値」だということでした。

React公式の State: A Component's Memory を読むと、stateはレンダーをまたいで保持され、stateの更新が再レンダーを引き起こすという整理になっています。

「stateを持つ」は何を意味するのか

記事内では「このコンポーネントがstateを持つ」と書きます。これは、その値をどのコンポーネントの責任として保持・更新するかという設計上の表現です。

function SearchInput() {
  const [keyword, setKeyword] = useState("")
  // ...
}

この場合は「SearchInput が keyword のowner」と考えます。

厳密には、Reactのstateはコンポーネントのコードそのものに格納されているわけではありません。Reactはstateをレンダーツリー上の位置と対応づけて管理しています。この記事では設計上の責任を説明するために「コンポーネントが持つ」という言い方をします。

ここまでなら useState の話です。ただ、実際の設計で迷うのは「この値をstateにするか」「どこに置くか」の方でした。

2. 問い1 — これは本当にstateか？

stateの置き場所を考える前に、不要なstateを消した方がシンプルになります。Reactの Thinking in React でも、まずUIが必要とする最小限のstateを特定する流れになっています。

`fullName` はstateにしなくていい

こんなコードを考えます。

const [firstName, setFirstName] = useState("Taro")
const [lastName, setLastName] = useState("Yamada")
const [fullName, setFullName] = useState("Taro Yamada")

fullName は firstName と lastName から計算できます。

const [firstName, setFirstName] = useState("Taro")
const [lastName, setLastName] = useState("Yamada")

const fullName = `${firstName} ${lastName}`

保存する値を減らすと、同期しなければならない値も減ります。

もし fullName までstateにすると、firstName を更新したときに fullName も忘れず更新する必要があります。つまり、stateを1個増やしたことで新しい同期処理も生まれます。

`filteredProducts` を保存すると何が起きるか

商品一覧でも同じです。

const [products, setProducts] = useState<Product[]>([])
const [filter, setFilter] = useState("")
const [filteredProducts, setFilteredProducts] = useState<Product[]>([])

filteredProducts が products と filter から毎回求められるなら、普通は保存しなくても作れます。

const [products, setProducts] = useState<Product[]>([])
const [filter, setFilter] = useState("")

const filteredProducts = products.filter(product =>
  product.name.includes(filter)
)

Reactの Choosing the State Structure では、冗長なstateや重複したstateを避ける方針が示されています。調べていて腹落ちしたのは、これは単なる「きれいなコード」の話ではなく、同期対象を増やさないための設計だという点でした。

stateかどうか迷ったときの見方

自分の中では、次の3つを確認すると整理しやすくなりました。

確認すること	当てはまるなら
親からpropsとして受け取っている？	その子自身のstateではない
既存のprops / stateから計算できる？	保存せず計算する
ユーザー操作などで時間とともに変わる？	state候補になる

これで「何を保存するか」が決まりました。残るのは、そのstateをどこが持つかです。

3. 問い2 — 誰がそのstateを持つのか？

ここが自分には一番分かりにくいところでした。「Input自身が持つ」「共通親が持つ」という言い方は、コンポーネントツリーを描くとかなり具体的になります。

親・子・共通親をツリーで見る

検索画面がこう分かれているとします。

function SearchPage() {
  return (
    <>
      <SearchInput />
      <SearchResult />
    </>
  )
}

コンポーネントの関係はこうです。

SearchPage は SearchInput と SearchResult の親です。

そして、SearchInput と SearchResult の両方から見たとき、最初に合流する上位コンポーネントが SearchPage です。これがこの記事でいう共通親です。

Inputだけが使うなら、Inputの近くに置く

たとえば入力欄のフォーカス状態を考えます。

function SearchInput() {
  const [isFocused, setIsFocused] = useState(false)

  return (
    <input
      onFocus={() => setIsFocused(true)}
      onBlur={() => setIsFocused(false)}
    />
  )
}

isFocused を SearchInput しか使わないなら、わざわざ SearchPage に上げる理由はありません。

「stateは上に置くほどよい」のではなく、必要な範囲に近い場所へ置く方が依存範囲を狭くできます。

兄弟が同じ値を使うなら共通親へ上げる

では keyword はどうでしょう。

SearchInput は現在の検索文字列を表示するために使います。SearchResult も、その文字列で検索結果を絞り込むために必要です。

もし keyword を SearchInput の中だけに置くと、こうなります。

兄弟である SearchResult は、SearchInput のローカルstateを直接読む設計にはなっていません。

そこで、keyword を両方の共通親である SearchPage に移します。

function SearchPage() {
  const [keyword, setKeyword] = useState("")

  return (
    <>
      <SearchInput
        keyword={keyword}
        onKeywordChange={setKeyword}
      />

      <SearchResult keyword={keyword} />
    </>
  )
}

SearchInput はpropsとして値を受け取り、変更したいときは親から渡された関数を呼びます。

type SearchInputProps = {
  keyword: string
  onKeywordChange: (keyword: string) => void
}

function SearchInput({
  keyword,
  onKeywordChange,
}: SearchInputProps) {
  return (
    <input
      value={keyword}
      onChange={e => onKeywordChange(e.target.value)}
    />
  )
}

構造はこうなりました。

子にあったstateを上位の共通親へ移すことを、Reactでは lifting state up と呼びます。Sharing State Between Components でも、複数コンポーネントを同期させるときは、stateを最も近い共通親に移す流れが紹介されています。

ここで「誰が値を書き換えるか」だけを見ないのもポイントでした。入力操作が起きるのは SearchInput ですが、keyword を必要としている範囲は SearchInput と SearchResult の両方です。だからownerは SearchPage になります。

Single Source of Truthは「全部global」ではない

keyword を SearchInput と SearchResult の両方に持たせる方法も、一見できそうです。

// SearchInput
const [keyword, setKeyword] = useState("React")

// SearchResult
const [keyword, setKeyword] = useState("React")

ただし、これは同じ意味の値が2つ存在する状態です。

片方だけ更新されたら、どちらが正しい keyword なのか分からなくなります。

Reactのドキュメントで出てくる Single Source of Truth は、「アプリのstateを全部1個のglobal storeに入れる」という意味ではありません。stateごとに、それを所有する場所を1つ決めるという考え方です。

「共有するならglobal store」と決め打ちすると、ドロップダウンの開閉のようなローカルな値までアプリ全体の依存になります。まずは最も近い共通親で足りるかを見る方が整理しやすいです。

Reduxの公式ドキュメントでも、すべてのstateをReduxへ入れる必要はなく、ローカルな値は最も近いUIコンポーネントに置く考え方が示されています。

4. 問い3 — 「owner」と「正本」は分けて考える

SearchPage が keyword のownerだと分かりました。ただ、「サーバーが本当の所有者」という表現まで混ざると、自分は同じ話に見えていました。

整理すると、これは別の軸でした。

React内のownerは「どのコンポーネントが保持・更新の責任を持つか」です。

一方、ここでいう正本は「そのデータの本物はどこにあるか」です。この2つを分けると、Local / Shared Client / Server / URLの違いが見やすくなりました。

Local State — そのUI周辺だけで使う

ドロップダウンの開閉や、入力途中の文字のように、特定のUI周辺だけで必要な値です。

function SortSelect() {
  const [isOpen, setIsOpen] = useState(false)
  // ...
}

他の画面が isOpen を必要としないなら、近くに置いたままで十分です。

Shared Client State — 離れたUIが共有する

ブラウザ側だけで意味を持ち、離れた複数の場所で共有したい値もあります。

たとえば、

テーマ
現在選択中のワークスペース
アプリ全体に影響するサイドバー状態

などです。

この範囲になるとContext、Redux、Zustandのような共有手段が候補になります。ただ、ここでも先に決めるのはライブラリではなく、「どこまでのUIがこの値を必要としているか」です。

Server State — ブラウザ側の値は原本ではない

APIから取得した products や users は、少し性質が違います。

商品の価格がブラウザに表示されていても、そのブラウザ内の値が唯一の正本ではありません。サーバー側で更新されれば、手元のデータは古くなります。

このためServer Stateには、ローカルstateではあまり出てこない問題があります。

論点	例
キャッシュ	取得済みデータを再利用する
stale	手元のデータが古くなっていないか
refetch	いつ取り直すか
mutation後の同期	更新後に表示をどう合わせるか

TanStack Queryのドキュメントを読むと、TanStack QueryはServer Stateを扱うライブラリとして、client state managerとは役割が違うと整理されています。

この区別を知ると、「APIの結果を全部Reduxに入れて自前で同期する」という設計が、なぜ大変になりやすいのかも見えやすくなりました。

URL State — 共有・復元したいならURLが自然な場合もある

商品一覧のページ番号やソート条件を考えます。

/products?page=3&sort=price

page=3 や sort=price をURLに持たせると、ブラウザの再読み込み後も状態が残ります。URLをそのまま共有でき、戻る・進むとも噛み合います。

React Routerでは useSearchParams を使ってsearch paramsを読み書きできます。

const [searchParams, setSearchParams] = useSearchParams()

const page = searchParams.get("page") ?? "1"

setSearchParams({
  page: "3",
  sort: "price",
})

React RouterのState Management でも、URL search paramsをstateの置き場所として扱う例が紹介されています。

useState に置けるかどうかだけで考えると見落としますが、「リロードや共有まで含めて、どこを正本にしたいか」で考えるとURLが自然なケースもあります。

5. 問い4 — stateは「置き場所」だけでなく「形」も設計する

ownerが正しくても、stateの中身に同じ情報のコピーや矛盾があれば、同期問題は残ります。Choosing the State Structure を読むと、stateは矛盾・冗長・重複を避ける方向で設計する考え方が繰り返し出てきます。

同じ情報をオブジェクトごと複製しない

商品一覧と選択中の商品を両方stateに持つ例です。

const [items, setItems] = useState([
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" },
])

const [selectedItem, setSelectedItem] = useState({
  id: 1,
  name: "Alice",
})

この形だと Alice の情報が2箇所にあります。

items 側だけ名前を更新すると、selectedItem に古い名前が残るかもしれません。

const [items, setItems] = useState([
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" },
])

const [selectedId, setSelectedId] = useState(1)

const selectedItem =
  items.find(item => item.id === selectedId)

選択状態として覚えるのは id だけにして、本体は items から探します。これなら Alice の本体は1箇所です。

booleanが増えると「ありえない状態」も作れる

送信フォームをこう持つとします。

const [isLoading, setIsLoading] = useState(false)
const [isSuccess, setIsSuccess] = useState(false)
const [hasError, setHasError] = useState(false)

この3つは独立したbooleanなので、型の上ではこういう状態も作れます。

isLoading = true
isSuccess = true
hasError = true

もし実際の画面が「送信中」「成功」「失敗」のどれか1つしか取らないなら、1つの値にした方が自然です。

type Status =
  | "idle"
  | "submitting"
  | "success"
  | "error"

const [status, setStatus] = useState<Status>("idle")

状態の関係も見やすくなります。

ここではstate machineまで踏み込みません。ただ、booleanが増えてきたときに「本当は1つの状態名として表せないか」と考えるだけでも、矛盾をかなり減らせそうです。

6. 4つの質問でstateの置き場所を決める

個別の原則だけだと、実装中にどの順で考えるか迷います。商品検索画面を使って、一連の判断にまとめると再利用しやすくなりました。

ProductPage
├── SearchBox
├── SortSelect
├── ProductList
└── Pagination

候補は次の5つです。

値	役割
`searchText`	検索文字列
`sort`	並び順
`page`	ページ番号
`products`	APIから取得した商品
`isSortMenuOpen`	ソートUIの開閉

自分なら、まずこの順で見ます。

この画面なら、たとえば次のように考えられます。

`products`

APIから取得する商品一覧なら、正本はサーバー側です。Server Stateとして扱うのが自然です。

`isSortMenuOpen`

SortSelect の表示だけに必要ならLocal Stateで足ります。

`page` と `sort`

再読み込みしても残したい、URLを共有したい、戻る・進むと連動させたいならURL Stateが合います。

`searchText`

ここは要件で変わります。検索欄と商品一覧の両方が使うだけなら ProductPage がownerになる形でも十分です。検索条件をURL共有したいならsearch paramsへ寄せる選択もできます。

こうして見ると、判断に使っているのは「ReduxかZustandか」ではありません。

本当に保存が必要か
誰が使うか
正本はどこか
重複や矛盾を作らない形か

コードレビューでも、stateが追加されたときにこの4つを聞けば、ライブラリ名より先に設計の意図を確認できます。

おわりに

state設計を調べる前は、useState、Context、ReduxのようなAPIの使い分けが中心だと思っていました。整理してみると、その手前にあるのは「このUIにとって正しい情報源はどこか」という問いでした。stateが増えたときほど、コードを足す前に情報の重複とownerを見る。この視点を持っていると、state管理ライブラリの選択もずっと理由のある判断になります。