問題タブ [react-redux]

最近、あるアプリでそれを行いましたが、これが悪い習慣と見なされるのか、それとも問題ないのかを知りたいです。2 つのアクションをリッスンするレデューサーがあるとします。

したがって、フローは次のとおりです。

• 発送しますPRE_FETCH_ACTION
• 外部 API へのフェッチ呼び出しを行います
• サービスの応答が返ってきたらディスパッチするFETCHED_SUCCESS

誰かがPRE_FETCH_ACTION最初のデータをディスパッチせずにデータをフェッチしようとすると、コードはエラーをスローします。

わかりました、これでうまくいきます。私の懸念は、私が言ったように、これが悪いパターンと見なされるかどうかです。なぜそう思うのですか？状態のisAllowed一部はレデューサーの内部にあるため、コンポーネントのレンダリング メソッドには影響しません。

私はこれの概念実証を持っていますが、これはうまくいくように見えますが、これが本当に良いアイデアなのか、Redux や代替戦略などを使用したより良い解決策があるのか​​ どうか、私の一部は疑問に思っています.

問題

基本的に、アプリケーション全体の基本的な React コンポーネントがあり、ヘッダー、メニュー、フッターなど、期待される典型的なコンポーネントがたくさんあります。

ツリーのさらに下 (さらに下) に、ヘッダー コンポーネント内に新しいメニュー項目をマウントできればすばらしいコンポーネントがあります。もちろん、ヘッダー コンポーネントはアプリケーションの一番上にあるため、アクセスは拒否されます。

それはほんの一例ですが、私がいろいろな角度から突きつけてきた問題事例です。

私のクレイジーな解決策

子コンポーネントがヘッダー内に表示したい追加要素を宣言できるようにする関数を公開するために、React のコンテキストを使用することを検討しました。

コンセプトをいじってみた後、最終的に、本質的に React Element メッセージング システムであるかなり一般的なソリューションにリファクタリングしました。このソリューションには 3 つの部分があります。

1. プロバイダー

Redux の Connect コンポーネントと同様の単一インスタンス コンポーネント。彼女は本質的に、メッセージを受信して​​渡すエンジンです。彼女の基本的な構造 (コンテキスト重視) は次のとおりです。

2.プロデューサー

より高次のコンポーネント。各インスタンスは、コンテキスト アイテムを介して要素を「生成」produceElementsし、特定の名前空間に要素を提供してから、(コンポーネントのアンマウントの場合) を介して要素を削除できremoveElementsます。

3. 消費者

より高次のコンポーネント。各インスタンスは、特定の名前空間に関連付けられた要素を「監視」するように構成されています。consumeElementsコールバック関数の登録を介してリッスンを「開始」しstopConsumingElements、消費を登録解除するために使用します。

---

それは私がやろうとしていることの大まかな概要です。基本的に、これはメッセージング システムです。そして、おそらくさらに抽象化することができます。

私はすでに redux を使用していますが、Redux が何に適していると思いますか? したがって、これは私にとってはうまくいっていますが、おそらくそれは良い設計ではなく、うっかりして Redux のつま先に立ったり、一般的なアンチパターンを作成したりしたと感じずにはいられません。

このために Redux をすぐに使用しなかった唯一の理由は、単純な状態ではなく要素を作成しているためだと思います。要素記述子オブジェクトを作成し、それを Redux 経由で渡すこともできますが、それ自体が複雑です。

---

知恵の言葉はありますか？

---

更新番号 1

上記に関する追加の説明。

これにより、完全なコンポーネント ツリーに要素を上下、さらには左から右に挿入できます。ほとんどの React Context の例では、祖父母から孫コンポーネントへのデータの注入について説明していることを知っています。

また、上記の実装では、コンテキストの使用に関する知識を開発者から抽象化する必要があります。実際、私はおそらくこれらの HOFS を使用して、ユース ケースに固有ではるかに明示的な追加のラッパーを作成するでしょう。

すなわち

消費者の実装:

プロデューサーの実装:

それは私が考えるかなり明確で、従うのは簡単です。ボタンを最も気にかけている場所に作成できるので、仲間とのより強い関係を築くことができます。

また、redux フローはおそらく正しい考えだと思います。自分自身でそれを難し​​くしているように感じます-このテクニックには何らかのメリットがあるのではないかと思わずにはいられません.

これが特に悪い考えである理由はありますか？

---

更新番号 2

わかりました、これは悪い考えだと確信しています。私は基本的に、アプリケーションの予測可能性を壊し、一方向データ モデルが提供するすべての利点を無効にしています。

Redux を使用することがこの場合の最適なソリューションであるとはまだ確信が持てませんが、コンテキスト マジックを使用せずに、上記の概念のいくつかを使用する、より明確な単方向ソリューションを思いつきました。

うまくいくと思われる場合は、解決策を回答として投稿します。それができない場合は、Redux に行って、すぐに皆さんの話を聞かなかったことを自責します。

---

その他の例

さまざまな手法を使用して同じ（っぽい）問題を解決しようとしている他のいくつかのプロジェクト/アイデアを次に示します。

https://joecritchley.svbtle.com/portals-in-reactjs

https://github.com/davidtheclark/react-displace

https://github.com/carlsverre/react-outlet

私はこれと長い間戦ってきました。誰かが私を正しい方向に向けることができますか? 問題: リストを作成すると、リストを更新/削除できます。アイテムを追加したり、これらのアイテムを更新/削除したりすることもできます。別のリストを追加すると、前者のアイテムが後者に引き継がれ、アイテムを編集できなくなります。リストを削除してブラウザを更新しないと、アイテムはリストに残ります。リストがそのアイテムについてのみ知っている方法で2つを結び付ける方法が必要です事前に助けてくれてありがとう。

/actions/lists.js

/actions/items.js

/reducers/lists.js

/reducers/items.js

/コンポーネント/List.jsx

/コンポーネント/List.jsx

/コンポーネント/Items.jsx

/コンポーネント/Item.jsx

/コンポーネント/App.jsx

react&reduxとともに.を使用して、基本的な Web アプリをセットアップしようとしていますwebpack。現状では、基本的なフレームワークをまとめただけですが、ビルドを実行すると常に次のエラーが発生するようです:

私が知る限り、それが不平を言っているjavascriptファイルですべてが正しく有効であるように見えます:

./app/views/index.js

./app/views/wrapper.js

./app/views/home.js

./app/index.js

構成に関しては、次のとおりです。

パッケージ.json

webpack.config.js

私はエラーに完全に困惑しています。私が間違っている場所について誰かが何か考えを持っているなら、私に知らせてください。ありがとう！

React + Redux + Normalizr を使用するアプリを持っています。何かが変更されたときにレンダリングの数を減らすためのベスト プラクティスを知りたいentitiesです。

エンティティ内のエンティティを 1 つだけ変更すると、その特定のエンティティを必要とするコンポーネントだけでなく、すべてのコンポーネントが再レンダリングされます

私はreact-reduxを初めて使用し、ベストプラクティスを取り上げてフレームワークを理解しながら、小さなWebアプリをまとめようとしています. 私の問題は、エコシステムが非常に多様であるため、なぜ物事が異なって見えるのか、いつもわからないことです.

私はボイラープレートを見ています、 https://github.com/choonkending/react-webpack-node/blob/master/app/containers/LoginOrRegister.jsx

私のコードはほとんど同じですが、アクションが呼び出されたように見えますが、レデューサーに到達していないか、アクションが呼び出されても実際にはディスパッチされていません。

私はそれを機能させることができず、そこに何が欠けているのか理解できず、愚かな気分になります。

私のconfigureStoreは以下のように見えますが、どうすればいいのかわかりません

---

中途半端

問題は promise ミドルウェアであることが判明しました。

私が使用していたボイラープレートは、次のようなカスタム ミドルウェアを使用していました。

私のコードでは、npm パッケージをインポートすることを選択しました。特に理由はありませんが、積極的に管理されているリポジトリを使用することを考えただけです。 https://www.npmjs.com/package/redux-promise-middleware .

問題を特定したら、これに切り替えましたが、すべて正常に機能しました。https://www.npmjs.com/package/redux-promise .

@dannyjoileは正しく、configureStoreに何か問題がありました。redux-promise-middleware をインポートしているときに、アクションが reduce に到達しませんでした。理由はわかりませんが、正直なところ、redux ミドルウェアについてはまだよくわかりません。

誰かが見たい場合は、githubですべてを入手しました。 https://github.com/ap-o/react-redux-material-passport

Reactでパーミッションチェックを処理するには? 2つの方法で試しました。許可チェックを処理するためのより良い方法、または使用するのに最も適した方法はありますか?

タイプ 1
コンテキストを介してパーミッションを渡します。権限が戻りコンポーネントまたは null を満たす場合、権限コンポーネントはコンテキストから権限を取得します

タイプ 2
mapStateToProps 関数でパーミッションを確認し、パーミッションに基づいて props を返します