Webアプリケーション開発におけるReactとReduxの秘密

読者の皆さん、こんにちは！ すぐに、ReactおよびReduxテクノロジーに関する新しい本があります。原本は2017年5月のO'Reillyです。



災害の規模、このような技術を使用してWebアプリケーションを作成する際に発生する可能性のある問題の範囲を説明するために、React、Redux、Typescriptの操作の複雑さを説明し、問題を排除および防止する方法を説明するSamuel Mendenhall（11月15日）の記事の要約翻訳を提供しますそのようなアプリケーションでのパフォーマンス。



はじめに



昨年、私たちのチームは、社内のアプリケーションの1つをAngularからReactに書き換えました。 以前は、多くの人がReactを扱っていましたが、「初心者」と「経験者」の両方がいました。 しかし、私たちは皆、このプロジェクトで多くの新しいことを学びました。特に、開発中に生じた、非効率性に苦しんでいた、同僚の成功した方法を研究した、または試行錯誤によって私たちにとって最適なものを見つけた痛み点を整理したとき。 それが私たちが得たものです。



Typescriptを使用しました



このプロジェクトで最も成功した決定の1つは、Typescriptを使用することです。 TypescriptとFlowを選択する必要がありました。 Flowには何もありませんでしたが、ワークフローにより適しているため、TypeScriptを停止しました。 私たちの場合のTypeScriptは単なる天の恵みであり、チーム全体としてコードベースを開発するとき、私たちはより自信を持つようになりました。 巨大なコードベースをリファクタリングする場合、3〜4回の呼び出しが深く、アプリケーションのさまざまな部分からの呼び出しが発生します。これは神経質です。 Typescriptを使用する場合、すべての関数を入力すると、不確実性はほぼ完全になくなります。 いいえ、もちろん、エラーの原因となる不正なコードまたは不完全なコードをTypeScriptに記述することは可能ですが、厳密に入力を厳守すると、いくつかのエラークラス（たとえば、間違った引数セットを渡す）が事実上消滅します。



Typescriptで泳いでいる場合、またはアプリケーションのリスクレベルを大幅に減らしたい場合は、Typescriptを使用してください。



ところで、私たちはtypestyle.github.io/#も使用しましたが、非常に満足しています。



厳格なコードスタイルと標準を持たない、および/またはJavaScriptで型チェックツール（FlowやTypescriptなど）を使用しない大規模なアプリケーションは避けてください 。 特に、Scala.jsなどの他のツールがここで役立ちます。



それどころか 、入力せずにjavascriptプロジェクトが長くなるほど、リファクタリングが難しくなることに注意してください。 型チェックによってリスクが完全に取り除かれることはありませんが、大幅に軽減されます。



バグを追跡する



チーム全体が行ったもう1つの非常に重要な決定は、Sentryを使用することでした： sentry.io/welcome 。 私は自然にエラーを追跡するための優れたツールは他にもあると確信していますが、私たちはセントリーから始めました。 Sentryを使用すると、まるで見ているように見えます。 そして最初の段階で、私たちはまるで盲目的に兄弟のように、実稼働環境に移動しました。 最初は彼らはテスターとユーザーに依存しており、製品のバグについて彼らから学ぶだろうと考え、ユーザーは常にテスターを逃したバグを見つけるでしょう。 これがセントリーが本当に助けた場所です。 リリースを正しく配布すれば、特定のリリース、特定のユーザーグループに集中し、実際にバグやエラーを防ぐことができます。 本番に入る前に多くのエラーをキャッチし、Sentryでコードの品質を分析しました。Sentryでは、予期しないデータの問題やその他の不明な状況を簡単に特定できます。



エラーを自動的にキャッチする機能を実現するまで、本番環境に入らないようにしてください。



Sentryまたはその他のエラー報告ツールとの連携が改善されました。



ビルドプロセスを合理化する



はい、時間をかけてください。 ローカルの開発ビルドに20秒かかるとしましょう。 プロジェクトに10人の開発者がいて、12分ごと、つまり1日に40回コードを再コンパイルするとします。 これは、1日800秒待機することになります。 就業日と年間1か月の休暇を考慮に入れると、各開発者は年間50時間、チーム全体は500人時を浪費することがわかります。 アセンブリ時間を簡単に短縮し、コンテキストの切り替えと待機に費やす時間を節約できる場合、これはささいなことではありません。



Webpack DLLの使用と開発側からの他の最適化のおかげで、再構築には2〜5秒しかかかりません。 また、モジュールのコード分割とホットリロードも使用します。つまり、変更されたモジュールのみがリロードされます。 アセンブリの機能を削減したバージョンもあるため、アプリケーションの特定の部分で作業し、アプリケーション全体を最初からコンパイルします。 webpackでは多くのトリックを実行できます。



AirBnBは、ビルドプロセスをどのように最適化したかに関する素晴らしいレポートを書きました： github.com/webpack/webpack/issues/5718 そこに記載されている最適化手法の多くは当社でも使用されていますが、他の最適化手法は使用されていません。



標準のwebpack-assemblyに限定されないようにしてください。かなり深い最適化を行うことをお勧めします。



いいえ、特定のアプリケーションの詳細を考慮してwebpackアセンブリをカスタマイズする必要があります。 たとえば、Typescriptを使用している場合、awesome-typescript-loaderに頼っていますが、そうでない場合は、祝福されたハックを使用します。



最新のJavascriptコンストラクトを使用しますが、これが何につながるかを覚えておいてください。 たとえば、async / awaitを使用すると、完全にクリーンな非同期コードを書くのに非常に便利です。 しかし、 Promise.all



を期待し、promiseの要素が実行されない場合、呼び出し全体が崩壊することを忘れないでください。 reduxアクションが構築されるのはこの計算です。さもないと、小さなAPIの障害が原因で、アプリケーション全体がロードされない可能性があります。



もう1つの非常に優れた設計は拡張演算子ですが、オブジェクトの平等の規則に違反するため、 PureComponent



を使用する自然な方法をバイパスすることにPureComponent



してPureComponent



。



Webアプリケーションのパフォーマンスに影響がある場合は、ES6 / ES7コンストラクトの使用を避けてください 。 たとえば、 onClick



でこの匿名の内部関数が本当に必要ですか？ 追加の引数を渡さない場合、ほとんどの場合必要ありません。



さまざまなデザインの効果をよりよく理解し、それらを合理的に使用します。



バベルが必要ですか？



古き良きJavascriptからTypescriptへの書き換えの最初の段階の1つでは、まだパイプラインにバベルがありました。 しかし、ある時点で、「このミックスでbabelは何をするのか」と自問しました。Babelは、目的のタスクを完全に解決する非常に貴重なライブラリですが、Typescriptを使用します。 バベルは必要ありません。 それなしでコードを書き直すことで、ビルドプロセスを加速し、1レベルの複雑さを取り除きました。



必要のないライブラリやダウンローダーを使用しないようにしてください 。 package.jsonまたはwebpackの設定を最後に確認し、未使用のローダーとライブラリを確認したのはいつですか？



ビルドツールチェーンとダウンロード可能なライブラリを定期的に確認することをお勧めします-おそらく何かを取り除くことができます。



あなたが持っている不要なライブラリを検討する



依存関係を更新する場合、常にある程度のリスクがあります。機能テスト、Typescript、および適切なアセンブリの助けを借りて減らすことができます。 更新されない場合、リスクはさらに高くなる可能性があります。 たとえば、主要な変更が行われたReact 16を考えてみましょう。React15の最近のバージョンでは、一部の依存関係がまだ新しいPropTypes標準に準拠しておらず、次のリリースで違反することを警告できます。 これらの警告は次のようになりました。



Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.







したがって、このような問題を解決する依存ライブラリを一度も更新したことがない場合、React 16にアップグレードすることはできません。



依存ライブラリの管理は、両刃の剣の一種です。 依存関係を修正する場合、最初はリスクを軽減しますが、将来、何かを修正したり、（潜在的に）最適化する機会を逃したりするリスクがあります。 一部のライブラリの依存関係はルールに従っていない場合があり、製品所有者は重要な修正を古いバージョンに移植しない場合があります。



この「スティック」の反対側-ライブラリのバージョンが頻繁に更新されると、強い依存関係が干渉する可能性があります。



ライブラリのコミットと更新のバランスを頻繁に見つけることができました。 この場合、妥協点があります。メインリリースを安定させたら、アプリケーションの強化の段階で依存関係を更新する時間を作ろうとします。



依存関係を修正せず、更新を拒否しないでください 。 さらに、リリースの直後に各メジャーリリースを更新する必要はありません。



依存関係リリースのチェックシーケンスをより適切に実行し、現在更新する価値があるものを評価し、アプリケーションの侵入段階でそのような更新を実行します。



スタックの弱点を知る



たとえば、 react-actions



とreact-redux



を使用しますが、欠点があります：アクション引数のタイプはアクションとリデューサー間でチェックされません。 このコンテキストでは、アクションを更新したときにいくつかの問題が発生しましたが、コンバーターの要素を更新するのを忘れ、型チェック中にキャッチされなかった不一致がありました。 この問題を回避する1つの方法は、すべての引数を含む単一のインターフェイスを記述し、それを操作することです。 この場合、この特定の共有インターフェイスを更新しているため、すべてのタイプが適切にチェックされます。



これをしないでください ：

 interface IActionProductName { productName: string; } interface IActionProductVersion { productVersion string; } const requestUpdateProductVersion = createAction(types.REQUEST_UPDATE_PRODUCT_VERSION, (productName: string, productVersion: string) => ({productName, productVersion}), null ); const receiveUpdateProductVersion = createAction(types.RECEIVE_UPDATE_PRODUCT_VERSION, (productName: string, productVersion: string) => ({productName, productVersion}), isXhrError ); [types.RECEIVE_UPDATE_PRODUCT_VERSION]: (state: ICaseDetailsState, action: ActionMeta): ICaseDetailsState => { // ... });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

大規模なアプリケーションでは、このアプローチはよりシンプルで、よりクリーンで、よりコンパクトですが、アクションとコンバーターの間のANDインターフェースでの型チェックが欠けています。 厳密に言えば、アクションとコンバーターの間にはまだ真の型チェックはありませんが、すべての引数に対して単一のインターフェイスがないため、リファクタリング時にエラーのリスクがあります。



より良いこれを行う：

 interface IActionUpdateProductNameVersion { productName: string; productVersion: string; } const requestUpdateProductVersion = createAction(types.REQUEST_UPDATE_PRODUCT_VERSION, (productName: string, productVersion: string) => ({productName, productVersion}), null ); const receiveUpdateProductVersion = createAction(types.RECEIVE_UPDATE_PRODUCT_VERSION, (productName: string, productVersion: string) => ({productName, productVersion}), isXhrError ); [types.RECEIVE_UPDATE_PRODUCT_VERSION]: (state: ICaseDetailsState, action: ActionMeta): ICaseDetailsState => { // ... });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

共通のinterfaces.IActionUpdateProductNameVersion



を使用する場合、このインターフェイスの変更はアクションとコンバーターの両方で取得されます。



ブラウザーでアプリケーションのプロファイルを作成する



Reactはパフォーマンスの問題があることを認めません。また、javascriptのプロファイリング情報を見ないと、実際にそれらを特定することは困難です。

多くのReact / Javascriptのパフォーマンスの問題は、次の3つのカテゴリのいずれかに該当すると思います。



最初：コンポーネントは更新されたかもしれませんが、更新されるべきではありませんか？ そして、次の問題：コンポーネントを更新するのは、単に表示するよりも費用がかかるのでしょうか？ 最初の質問に答えるのは簡単ですが、2番目の質問に答えるのはそれほど簡単ではありません。 しかし、最初の質問に答えると、 github.com/MalucoMarinero/react-wastage-monitorのようなものを使用できます。これは簡単です。 ツールは、コンポーネントが更新されたが、そのプロパティが変更されていない場合、そのような場合についてコンソールに通知します。 この特定の目的のために、彼は良いです。 node_modulesを適切に除外することができなかったため、このライブラリを使用して最適化を実行し、無効にしました。それ自体が不完全であるため失敗しました。プロパティなどの機能に依存します。 各ツールは、目的に適しています。



Javascript最適化の2番目のカテゴリは、プロファイリングによって達成されます。 コードに予想よりも遅いセクションがありますか？ メモリリークはありますか？



グーグルはこの主題に関して素晴らしい助けをした。



developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference and developers.google.com/web/tools/chrome-devtools/memory-problems



3番目のカテゴリは、不要な呼び出しと更新の排除です。 この最適化は最初のものとは異なります。 次に、コンポーネントを更新する必要があるかどうかを確認しました。 この場合、最適化は、呼び出しがまったく必要かどうかの質問から始まります。 したがって、このようなミスを犯すことは価値がありません。バックエンドから同じコンポーネントに誤って多くの呼び出しを送信します。



これに限定されないようにしてください ：

 componentWillReceiveProps(nextProps: IProps) { if (this.props.id !== nextProps.id) { this.props.dispatch(fetchFromBackend(id)); } } export function fetchFromBackend(id: string) { return async (dispatch, getState: () => IStateReduced) => { // ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より良いこれを行う：

 componentWillReceiveProps(nextProps: IProps) { if (this.props.id !== nextProps.id && !nextProps.isFetchingFromBackend) { this.props.dispatch(fetchFromBackend(id)); } }   ,        : export function fetchFromBackend(id: string) { return async (dispatch, getState: () => IStateReduced) => { if (getState().isFetchingFromBackend) return; ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は少し工夫されていますが、すべてがロジックの中で整然としています。 コンポーネントでcomponentWillReceivePropsが機能する場合に問題が発生しますが、最初からバックエンドからの呼び出しが必要かどうかのチェックをインストールしなかった場合、無条件に実行されます。



さまざまなクリックや引数の変更に対処する必要がある場合、問題はさらに複雑になります。 販売注文を表示していて、コンポーネントを新しい注文で再表示する必要がある場合、これが起こる前に、ユーザーは別の場所をクリックして新しい注文を行うことができます。 このような非同期呼び出しを行うことは、常に決定的ではありません。 さらに、バックエンドでの予期しない遅延が原因で、最初の非同期呼び出しが2番目の非同期呼び出しよりも後に行われた場合はどうなりますか？ その後、ユーザーには間違った順序が表示されます。 上記のコード例では、この問題は影響も受けませんが、このようなコードでは、1つの呼び出しが行われている間に多くの呼び出しを行うことはできません。 最終的に、このような仮想の状況に対処するために、次のように、コンバーターでキーアクセスを持つオブジェクトを作成する必要があります。

 objectCache: {[id: string]: object}; isFetchingCache: {[id: string]: boolean};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンポーネントには常にクリックされた最後のid



へのリンクが含まれ、 isFetchingCache



は最後のid



マークされます。



ReactとJavaScriptを使用する際に発生する可能性があるすべてのパフォーマンスの問題が上記で考慮されるわけではないことに注意してください。 特に、一度リデューサーを呼び出したときにパフォーマンスの低下に遭遇したことがあります。 問題の原因は、reduxのAPIからの応答に非常に深く埋め込まれた大きなオブジェクトがあるためであり、ディープクローニングのパフォーマンスが損なわれていることが判明しました。 ChromeでJavaScriptをプロファイリングすることで問題をキャッチできました。クローン機能がしばらく使用されたときに、問題がすぐにわかりました。