脱Reduxを試みて失敗した話、その原因と対策について
さて、年末が近づいてきましたが今年も 「Redux 使うべき使わないべきか」という話で盛り上がりましたね。 僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。 自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。 自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです
reducer の ノーマライゼーション - Qiita
本来は実体を配列で保持するようなケースを、次のような構成に分ける reducerが返すある状態を、全体を保持するオブジェクトと、全体の各IDを保持する配列に分ける。 全体を保持するオブジェクトのキーを指定して実体を手に入れる。まとまりをそのまま処理する場合は、全体の各IDを保持する配列にmap()を適用し、必要な実体のリストを手に入れる。 なぜ、こうするのか redux のアプローチでは、情報を管理するストアはトップレベルに一つだけある。そしてこのストアは意味のあるデータの塊ごとに reducer を作成し、必要に応じて combineReducers することで合成することができる。擬似的には
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
