[react]第11章:素子性能の最適化
10章で作成したTo Do Appに大量のデータがある場合、アプリケーションは遅くなります.
App.jsファイルを修正して、たくさんのデータをレンダリングしましょう.
#createBulkTodosは、繰り返し文で大量のデータを追加する関数です.
構成部品が再レンダリングされる場合は、次のようになります.
1.受け取ったアイテムが変わったとき
2.自分の状態が変わったとき
3.親構成部品を再レンダリングする場合
4.forceUpdate関数を実行する場合
したがって、不要に構成部品を再レンダリングすることを防止する必要があります.
導出要素の構文に反応します.簡単にmemo(素子名)に変更するだけです.
これにより、構成部品のpropsが変わらない場合、レンダリングを行わないように設定されます.
したがって、次の写真では、TodoListItemコンポーネントのprops todo、onRemove、onToggleが変更されていない場合は、再レンダリングされません.
多くの固定データでは,1つの関数だけを更新しても,毎回関数を再生成するのは効率的ではない.
したがって、関数の生成を続行しない方法については、(2)、(3)番号を参照してください.
既存のusStateのsetter関数を使用する場合、パラメータを使用して新しい状態が追加されます.
次の図は、新しいスケジュールを追加するときに実行する関数です.
もちろん、以前は2番目のパラメータを使用して、関数がを生成するたびにtodos配列が変更されたときにのみ生成されることを防止していました.
ただし、setter関数のパラメータに更新関数を追加し、パラメータに新しい状態を追加しない場合は、2番目のパラメータにtodos配列を追加する必要はありません.既存のパラメータの前にtodos=>を追加し、2番目のパラメータの配列をクリアするだけです.
上記(2)次方法の代替方法として用いることができる.
useReducerの最大の利点は、ステータス更新ロジックをコンポーネントの外に統合できることです.
usereducerを使用する例として、スケジュールを追加する関数コードを以下に示します.
下の写真から見ると2500枚の中で9枚しか見えません.この9つしかありませんが、残りの2491のスケジュールもスクロール前にレンダリングされているため、効率が低下します.
したがって、react仮想化ライブラリを使用してスクロールする前に、レンダリングされていない場合にのみサイズが使用され、スクロール時にのみ使用されます.このスクロール位置に表示される構成部品をレンダリングしてみます.
$ yarn add react-virtualized
react-仮想化で提供されるListコンポーネントを使用すればよい.リスト構成部品を使用するための新しい関数を作成し、リスト構成部品のpropsに設定すればよい.
react仮想化リストコンポーネントにrowRender関数を作成し、スケジュール内の各スケジュールをレンダリングします.
ちなみに,リストコンポーネントとしてのpropsのためには,開発者ツールによりあらかじめ一定の大きさや高さを決定する必要がある.
反応素子のレンダリングは基本的に高速であるため、各素子の性能を最適化するためには圧力は必要ありませんが、リストに関連する素子があり、常に更新されている場合は、最適化が必要です.
App.jsファイルを修正して、たくさんのデータをレンダリングしましょう.
1.大量のデータをレンダリング
(1)userStateのデフォルト値を関数として使用する.
#createBulkTodosは、繰り返し文で大量のデータを追加する関数です.
const [todos, setTodos] = useState(createBulkTodos);
userStateのデフォルト値がcreateBulkTodos()として指定されている場合、createBulkTodos関数はレンダリングのたびに実行されますが、括弧なしのcreateBulkTodosとして指定されている場合、createBulkTodos関数は最初のレンダリング時にのみ実行されます.2.遅くなる原因分析
構成部品が再レンダリングされる場合は、次のようになります.
1.受け取ったアイテムが変わったとき
2.自分の状態が変わったとき
3.親構成部品を再レンダリングする場合
4.forceUpdate関数を実行する場合
したがって、不要に構成部品を再レンダリングすることを防止する必要があります.
3.構成部品のパフォーマンスの最適化
(1) React.memoの使用
導出要素の構文に反応します.簡単にmemo(素子名)に変更するだけです.
これにより、構成部品のpropsが変わらない場合、レンダリングを行わないように設定されます.
したがって、次の写真では、TodoListItemコンポーネントのprops todo、onRemove、onToggleが変更されていない場合は、再レンダリングされません.
多くの固定データでは,1つの関数だけを更新しても,毎回関数を再生成するのは効率的ではない.
したがって、関数の生成を続行しない方法については、(2)、(3)番号を参照してください.
(2)usStateの関数式更新機能
既存のusStateのsetter関数を使用する場合、パラメータを使用して新しい状態が追加されます.
次の図は、新しいスケジュールを追加するときに実行する関数です.
もちろん、以前は2番目のパラメータを使用して、関数がを生成するたびにtodos配列が変更されたときにのみ生成されることを防止していました.
ただし、setter関数のパラメータに更新関数を追加し、パラメータに新しい状態を追加しない場合は、2番目のパラメータにtodos配列を追加する必要はありません.既存のパラメータの前にtodos=>を追加し、2番目のパラメータの配列をクリアするだけです.
(3) useReducer
上記(2)次方法の代替方法として用いることができる.
const [todos, dispatch] = useReducer(todoReducer, undefined, createBulkTodos);
userreducerを使用する場合、上記のように初期値を2番目のパラメータとして使用すると、createBulkTodos関数は最初のレンダリング時にのみ呼び出されます.useReducerの最大の利点は、ステータス更新ロジックをコンポーネントの外に統合できることです.
usereducerを使用する例として、スケジュールを追加する関数コードを以下に示します.
4.仮想化によるレンダリングの最適化
下の写真から見ると2500枚の中で9枚しか見えません.この9つしかありませんが、残りの2491のスケジュールもスクロール前にレンダリングされているため、効率が低下します.
したがって、react仮想化ライブラリを使用してスクロールする前に、レンダリングされていない場合にのみサイズが使用され、スクロール時にのみ使用されます.このスクロール位置に表示される構成部品をレンダリングしてみます.
$ yarn add react-virtualized
react-仮想化で提供されるListコンポーネントを使用すればよい.リスト構成部品を使用するための新しい関数を作成し、リスト構成部品のpropsに設定すればよい.
react仮想化リストコンポーネントにrowRender関数を作成し、スケジュール内の各スケジュールをレンダリングします.
ちなみに,リストコンポーネントとしてのpropsのためには,開発者ツールによりあらかじめ一定の大きさや高さを決定する必要がある.
反応素子のレンダリングは基本的に高速であるため、各素子の性能を最適化するためには圧力は必要ありませんが、リストに関連する素子があり、常に更新されている場合は、最適化が必要です.
Reference
この問題について([react]第11章:素子性能の最適化), 我々は、より多くの情報をここで見つけました https://velog.io/@jooyeon/React-11장-컴포넌트-성능-최적화テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol