【React x Redux状態管理】Reduxが保存するべき値かlocalStateでもつべきかのチェックポイント

【React x Redux状態管理】Reduxが保存するべき値かlocalStateでもつべきかのチェックポイント

今現場ではリファクタリングをしようとしています。
リリースに間に合わせるためにガツガツ書いてきたところをしようとするフェーズらしくて。
React x Reduxを扱っている方なら誰もがこれを考えたことがあると思うけど、ちゃんと書いてあった。Redux自信が、全てのstateをReduxがもつ必要はないとしていた。気づかなかった。
今深夜で眠いので、さっとドラフト記事書きます

Do I have to put all my state into Redux? Should I ever use React's setState()?

すべての状態をReduxに入れる必要がありますか? ReactのsetState()を使用する必要がありますか?

https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate

Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Do you want to keep this data consistent while hot-reloading UI components (which may lose their internal state when swapped)?
There are a number of community packages that implement various approaches for storing per-component state in a Redux store instead, such as redux-ui, redux-component, redux-react-local, and more. It's also possible to apply Redux's principles and concept of reducers to the task of updating local component state as well, along the lines of this.setState( (previousState) => reducer(previousState, someAction)).

  • アプリケーションの他の部分はこのデータを気にしますか?

  • この元のデータに基づいて、さらに派生データを作成できるようにする必要がありますか?

  • 複数のコンポーネントを駆動するために同じデータが使用されていますか?

  • この状態を特定の時点に戻すことができる(つまり、タイムトラベルデバッグ)ことに価値はありますか?

  • データをキャッシュしますか(つまり、データを再要求するのではなく、すでにそこにある場合は状態を使用します)?

  • UIコンポーネントをホットリロードしている間、このデータの整合性を維持しますか(スワップすると内部状態が失われる可能性があります)

    フォームの値は??

Most form state shouldn't go in Redux. In most use cases, the data is not truly global, is not being cached, and is not being used by multiple components at once. In addition, connecting forms to Redux often involves dispatching actions on every single change event, which causes performance overhead and provides no real benefit. (You probably don't need to time-travel backwards one character from name: "Mark" to name: "Mar".)

Even if the data ultimately ends up in Redux, prefer keeping the form edits themselves in local component state, and only dispatching an action to update the Redux store once the user has completed the form.

formの状態はグローバルでもなく、他のコンポーネントと共有することもない。 保存する場合でも、全てのユーザー更新が終わったとき一度だけReduxにdispatchすればいい。(恐らくsubmit時)

上のようにredux-styleguideに書いてある。(onChangeごとにアクションを発行するとパフォーマンスに影響がでる)
https://redux.js.org/style-guide/style-guide#avoid-putting-form-state-in-redux

全然関係ないけど
https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape#designing-a-normalized-state
ここら辺もやる


「武骨日記の」プライバシーポリシーに関して
プライバシーポリシー
個人情報取り扱いに関して

サイトTOP
私は何者か
29歳よしもと芸人がWebデザイナー未経験で学校に通い5年後フリーランスのフロントエンドエンジニアになるためにやった9つのこと
フロント記事
フロントエンドエンジニア
フロントエンド記事(タグ)
TypeScript
TypeScript練習問題集
【TypeScript】TypeSript中級者になる為に知っておくと良い108個のこと
JavaScript練習問題
styled-componentsの使い方
SCSS問題集
GraphQL「Apollo x Relay-Style-Cursor-Pagination(リレースタイルカーソルページネーション)」
recomposeと仲良くなりたい
機動戦士FlowType
初めてReactNativeWebを触ってみて
Ramda.jsシグネチャの読み方
環境変数の話
いちごタルトの作り方
フロントエンドエンジニア豚汁の作り方


「武骨日記の」プライバシーポリシーに関して
プライバシーポリシー

株式会社TerraceTechについて
最近起業しました。
株式会社TerraceTech

SNS
インド旅 instagram
適当な日常写真 instagram
シュールさーん instagram
シュールさーん LINEスタンプ
もりたけんじTwitter
ネタ帳Twitter
note

FaceBook -kennji.morita-

わたしが結成しているWebチームではWeb未経験者、フリーランスの方へのお仕事を紹介しています。
また個人レッスンしてほしい生徒も募集中です。
もしご興味ある方はチャットからご連絡ください。

※業務連絡やお久しぶり連絡もチャットからお願いします。