Redux: スマートコンポーネントとダムコンポーネントの間の「ハッピーメディア」はどこにありますか？

以前のバージョンのドキュメントでは、接続されたコンポーネントが少ない方が良いと言っていましたが、それがどれほどのカーゴカルトになるかは予想していませんでした。 😞はい、すべてのコンポーネントを接続することはしばしばやり過ぎですが、すべてを一番上に置くこともそうです！ dispatchを取得するためだけに接続することは特に無害なので、これを頻繁に行うことについて悪く感じることはありません。

あなたのコードは私には絶対にうまく見えます。 👍

ありがとうございました。 少なくとも、私のコードは問題なく、おそらくより良い会社で仕事を得るという強い主張があります:)

しかし、それでもconnectがやり過ぎであるシナリオをイメージすることはできません。 このスキルを開発して、このデータを使用しない親コントロールから子コントロールにデータを渡すか、コードに別のconnectを含める（特にデータの小さなチャンクを読み取る場合）どのルールを破る必要があるかを知る方法ストアから）？

アプリ内の多くのconnectどのような問題が発生しますか？

Reduxのサブスクライバー通知プロセスは、すべてのサブスクライバーコールバックを実行する単純なループであるため、明らかにO（n）です。 理論的には、サブスクライバーコールバックが複雑な処理を行っている場合、またはサブスクライバーの数が_非常に_大きくなる場合、パフォーマンスの問題になる可能性があります。

実際には、それはおそらくそれほど問題ではありません。 現実的に問題になる前に、数千のアクティブなサブスクリプションが必要であり、多くのアクションが1秒間にディスパッチされる必要があると思います。 現時点では、それを検証するために指摘できる特定のベンチマークはわかりません（ただし、最近のMobX / Reduxの比較が関係している場合を除きます）。

全体として、私はあなたが古典的な「それを機能させ、正しくし、速くする」アプローチに従って安全であるべきだと思います。 アプリケーションの機能を適切に機能させるコードを記述します。 あなたが書いたものを見て、必要に応じて構造を調整して、より意味のあるものにします。 遅いと思われる場合は、測定してベンチマークを行い、実際に遅い部分を修正します。