Reactの状態管理の変遷に関する自分史 From 2014 To 2022
はじめに 2014年にReactを触りはじめて以降、2022年現在まで集中の度合いにバラツキはあるものの、ずっとReactでなんらかのアプリケーションを書いてきました。 その中で様々なアーキテクチャや設計に関する議論がありましたが、特に状態管理についての変遷を自身の体験をもとにまとめてみたいと思います。 多分に昔話的な内容なものの、適度に読み飛ばしてもらいつつ、Reactの状態管理のやや偏った歴史と現在地点の認識の共有になればと思います。 2014- | Reactの導入 - Flux SPA iPhone 4Sが出てスマートフォンを持つ人も多くなり、エンジニアでなくても多くの人が日常的にGmailやMapアプリケーションに触れるようになった時期だったと記憶します。 Webアプリケーションの構築でもフロントエンドへの要求レベルが高くなっていた感覚があり、JavaScriptで動的なView
ぼくのかんがえたさいきょうの useState + useContext よりも Redux のほうが大抵勝っている
「Redux は学習コストが高い」などと言って useState（または useReducer）と useContext を組み合わせ 劣化 オレオレ Redux を作ってしまうのを見かけます[1]。よくないことだと思いますが、気持ちは非常にわかります。Redux エコシステムがそういう気持ちにさせてしまう部分は大いにあります。 Redux は それ単体なら 学習コストは useReducer + useContext と同等であることを示してこの気持ち（誤解）を解かしつつ、なぜそういう気持ちになってしまうのか考察してみます。 まず useState と useReducer の違いを押さえておく 知っている方はスキップしてください。 useState と useReducer は本質的には同等で、どちらもコンポーネントにステート（状態）を持たせる役割があります。次のようなカウンターアプリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
