複数の状態コンポーネントが反応するアプリケーションにどのような影響を与えますか？

Question

ドキュメントによれば、状態を持つ複数のコンポーネントを持つことを避けるべきです。私は、ユーザが書くときに自動的に垂直方向に拡大するテキストボックスを作成したいという状況におり、そのために私はこのトリックhttp://www.impressivewebs.com/textarea-auto-resize/を使用しています。つまり、コンポーネントの高さを取得する必要があります。さて、私はそれをちょっと試してみましたが、状態を含む親コンポーネントにrefを渡すことは現実的ではないので、簡単な方法はコンポーネントの状態をテキストボックスを開き、そこからrefを使用します。

これは私に、複数の状態コンポーネントがアプリケーションにどのように悪影響を及ぼすかを考えさせました。保守性/理解可能性のみですか？それとも実際のパフォーマンス上の問題がありますか？私はあなたのアプリケーションの状態を維持するためにプラグインする多くのオープンソースのコンポーネントを気付いています。つまり、オープンソースのコンポーネントを使用すると、アプリケーションに複数の状態コンポーネントがある可能性があります。

Answer 1

DOMのこの種のトリックには、ローカル状態を使用するのは大丈夫です。親コンポーネントにそのような実装の詳細を共有するよりも、より良いアプローチです。

一般的に、状態のためのこの場所を使用する：店舗で

1. アプリケーション全体のデータを外部
2. フォーム一時データもストアに配置することができる（Reduxの、フラックス店舗、観測）に反応します。しかし、フォーム以外の場所では必要がない場合は、このデータをフォームコンポーネントに配置することをお勧めします。ただ

---

それを必要とするDOM、短い生活と非常に局所的な状態は、コンポーネントに配置することが可能に

トリックはそれであり、実際のパフォーマンスの問題がありますか？

すべての状態をコンポーネントに配置すると、アプリケーションはさらに高速になります。ローカル状態を更新すると、このコンポーネントとその子コンポーネントのみが更新されるためです。

しかし、メンテナンス性が損なわれるので、これを行うべきではありません。それは悪いコンポーネントだ - オープンソースの

多くのコンポーネントは、あなたが小道具を通してそれを制御することができない場合あなたは自分のアプリにプラグインでしょうコンポーネントが状態

を保つ反応します。通常、オープンソースのコンポーネントは使いやすくなるように書かれていますので、のデフォルト値はとなり、アプリケーションにコンポーネントを配置して喜んで利用できます。

例：タブコンポーネントは通常、ローカル状態を使用して選択したタブを制御します。また、selectedTabとコールバックonSelectが必要なので、自分でコントロールすることもできます。

Answer 2

愚かなコンポーネント（テキストエリアのコンポーネントなど）は、データを持つ状態を持つべきではありません。しかし、彼らは独自のUI状態を持つことができます。
この場合、愚かなコンポーネントの状態でテキストエリアの高さを簡単に維持できます。