博士

やあ、ロボ子！今日はHarborの臨床試験データキャプチャUIのパフォーマンス改善の話じゃ。

ロボ子

博士、こんにちは。HarborのUI、初期プロトタイプでパフォーマンス問題があったんですね。具体的にどんな問題だったんですか？

博士

`useState`と`Context`を使ってたんじゃが、データ構造が複雑でコンポーネントツリーも深かったから、再レンダリングが頻発したみたいじゃな。

ロボ子

なるほど。それで、どう解決したんですか？

博士

そこで登場するのが、atomic stateじゃ！Jotaiライブラリを使って、状態を細かく分割して管理するようにしたんじゃ。

ロボ子

atomic stateですか。Jotaiを使うと、具体的に何が変わるんですか？

博士

Jotaiは、状態のサブセット（atoms）へのアクセスを提供するから、関係のない状態が変わっても再レンダリングをスキップできるんじゃ。つまり、必要な部分だけが更新されるようになる。

ロボ子

効率的ですね！Jotaiの導入は難しかったですか？

博士

`useState`に似たhookベースのAPIだから、開発者も導入しやすかったみたいじゃぞ。各コンポーネントが依存する状態ごとにatomsを作って、変更があった時だけ再レンダリングするようにしたんじゃ。

ロボ子

`useState`のようなAPIで状態にアクセスできるのは便利ですね。コンポーネントレベルのコードを大幅に変更せずにatomic stateを採用できるのは大きなメリットですね。

博士

そうじゃ！状態を"in React"に保ちつつ、コンポーネントコードを慣用的かつ宣言的に保てるのがミソじゃな。内部状態が変わるたびに大規模な再レンダリングが起こるようなコンポーネントを出荷するコストなしに、パフォーマンス改善できるんじゃ。

ロボ子

Jotaiすごいですね！私も使ってみたくなりました。

博士

じゃろじゃろ？ロボ子もatomic stateマスターになるのじゃ！

ロボ子

はい、頑張ります！ところで博士、Jotaiって名前、ちょっと可愛いですよね。

博士

ふむ、そうじゃな。まるでロボ子のためにあるような名前じゃ！…って、私が言いたかったのは、Jotaiを使うと状態管理が『冗談みたいに』簡単になる、ってことじゃ！