技術

Reactチュートリアル：コンポーネント、フック、パフォーマンス

で指摘されたように Reactチュートリアルの最初の部分、Reactの使用を開始するのは比較的簡単です。 Create React App（CRA）を使用して開始し、新しいプロジェクトを初期化して、開発を開始します。悲しいことに、時間の経過とともに、特にReactを初めて使用する場合は、コードの保守がかなり難しくなる状況に遭遇する可能性があります。コンポーネントが不必要に大きくなったり、コンポーネントである可能性があるがそうではない要素になってしまう可能性があるため、あちこちで繰り返しコードを記述してしまう可能性があります。

ここで、Reactの旅を実際に始めようとする必要があります。 React開発ソリューション。

新しいアプリ、後でReactアプリケーションに変換する必要のある新しいデザインに近づくときはいつでも、最初にスケッチに含めるコンポーネント、スケッチを分離して管理しやすくする方法、および要素を決定するようにしてください。反復的（または少なくともそれらの動作）。「将来的に役立つ」可能性のあるコードを追加しないようにしてください。魅力的かもしれませんが、その将来は到来しない可能性があり、構成可能なオプションが豊富な追加の汎用関数/コンポーネントを保持します。

Reactチュートリアル：Reactコンポーネントの図

また、コンポーネントが2〜3ウィンドウの高さよりも長い場合は、後で読みやすくなるため、（可能であれば）分離する価値があるかもしれません。

Reactの制御コンポーネントと非制御コンポーネント

ほとんどのアプリケーションでは、ユーザーが何かを入力したり、ファイルをアップロードしたり、フィールドを選択したりできるようにするために、入力とユーザーとの何らかの形の対話が必要です。 Reactは、2つの異なる方法でユーザーインタラクションを処理します。制御そして 制御されていない コンポーネント。

制御されたコンポーネントの値は、その名前が示すように、ユーザーと対話する要素に値を提供することによってReactによって制御されますが、制御されていない要素はvalueプロパティを取得しません。そのおかげで、たまたまReact状態である信頼できる唯一の情報源があるため、画面に表示されているものと現在の状態にあるものとの間に不一致はありません。開発者は、フォームに対するユーザーの操作に応答する関数を渡す必要があります。これにより、フォームの状態が変更されます。

class ControlledInput extends React.Component { state = { value: '' }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( ); } }

制御されていないReactコンポーネントでは、値がどのように変化するかは気にしませんが、正確な値を知りたい場合は、refを介してアクセスするだけです。

class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( ); } }

では、どちらをいつ使用する必要がありますか？ほとんどの場合、制御されたコンポーネントが最適な方法だと思いますが、いくつかの例外があります。たとえば、Reactで制御されていないコンポーネントを使用する必要がある1つのケースは、fileです。値は読み取り専用であり、プログラムで設定できないため、inputと入力します（ユーザーの操作が必要です）。また、制御されたコンポーネントは読みやすく、操作しやすいと思います。制御されたコンポーネントの検証は再レンダリングに基づいて行われ、状態を変更でき、入力に問題があること（フォーマットや空など）を簡単に示すことができます。

参照

refsについてはすでに説明しました。これは、フックが16.8に登場するまで、クラスコンポーネントで使用可能だった特別な機能です。

参照は、参照を通じて開発者にReactコンポーネントまたはDOM要素（参照をアタッチするタイプに応じて）へのアクセスを与えることができます。コードを読みにくくし、上から下へのデータフローを中断するため、これらを回避し、必須のシナリオでのみ使用することをお勧めします。それでも、特にDOM要素で必要な場合があります（たとえば、プログラムでフォーカスを変更するなど）。 Reactコンポーネント要素にアタッチする場合、参照しているコンポーネント内からメソッドを自由に使用できます。それでも、これに対処するためのより良い方法があるため、この方法は避ける必要があります（たとえば、状態を上げて関数を親コンポーネントに移動する）。

どこにコードを書くことができますか

参照には、3つの異なる方法があります。

文字列リテラルを使用する（レガシーであり、避ける必要があります）、
ref属性に設定されているコールバック関数を使用して、
refをReact.createRef()として作成するそしてそれをクラスプロパティにバインドし、それを介してアクセスします（参照はcomponentDidMountライフサイクルから利用可能になることに注意してください）。

最後に、参照が渡されない場合や、現在のコンポーネントからより深い参照要素にアクセスしたい場合があります（たとえば、insideDOM要素を持つコンポーネントがあり、現在はコンポーネント内にあり、行からDOMフォーカス関数を入力するためにアクセスしたいコンポーネント。ここでforwardRefを使用します）。

参照が渡されない1つのケースは、 高階コンポーネント コンポーネントで使用されている-理由はrefとして非常に理解できます。 propではありません（keyと同様）したがって、受け継がれないため、HOCを参照します。コンポーネントがラップされる代わりに。このような場合、React.forwardRefを使用できます。これは、小道具と参照を引数として取り、propに割り当てることができます。アクセスしたいコンポーネントに渡されます。

function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return ; } } return React.forwardRef((props, ref) => { return ; }); }

エラー境界

物事が複雑になるほど、何かがうまくいかない可能性が高くなります。それが理由です エラー境界 Reactの一部です。では、それらはどのように機能しますか？

何か問題が発生し、その親としてエラー境界がない場合、Reactアプリ全体が失敗します。ユーザーを誤解させて間違った情報を表示するよりも、情報を表示しない方がよいですが、必ずしもアプリケーション全体をクラッシュさせて白い画面を表示する必要があるという意味ではありません。エラー境界を使用すると、使用できる柔軟性が向上します。アプリ全体で使用してエラーメッセージを表示するか、一部のウィジェットで使用して単に表示しないか、代わりにそれらのウィジェットの代わりに少量の情報を表示することができます。

一部のイベントや呼び出しを処理するために作成する命令型コードではなく、宣言型コードの問題のみに関することを忘れないでください。これらについては、通常のを使用する必要があります 試して/キャッチ アプローチ。

エラー境界は、情報をに送信できる場所でもあります。 エラーロガー （componentDidCatchライフサイクルメソッドで）使用するもの。

class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return Help, something went wrong. ; } return this.props.children; } }

高階コンポーネント

高次コンポーネント（HOC） Reactでよく言及されており、非常に人気のあるパターンであり、おそらく使用する（またはすでに使用している）パターンです。 HOCに精通している場合は、おそらくwithNavigation, connect, withRouterを見たことがあるでしょう。多くの図書館で。

HOCは、コンポーネントを引数として取り、HOCラッパーのないコンポーネントと比較して拡張機能を備えた新しいコンポーネントを返す単なる関数です。そのおかげで、コンポーネントを強化できるいくつかの簡単に拡張可能な機能を実現できます（ナビゲーションへのアクセスなど）。 HOCは、私たちが持っているものに応じて呼び出されるいくつかの形式を取ることもできます。常に必要な唯一の引数はコンポーネントですが、追加の引数を取ることもできます。いくつかのオプション、またはconnectのように、最初に次のような構成で関数を呼び出します。後で引数コンポーネントを取り、HOCを返す関数を返します。

追加でき、避けるべきことがいくつかあります。

ラッパーHOC関数の表示名を追加します（実際には、HOCコンポーネントの表示名を変更することでHOCであることがわかります）。
レンダリングメソッド内でHOCを使用しないでください。常に再マウントして現在の状態を失うため、新しいHOCコンポーネントを作成するのではなく、既に拡張コンポーネントを使用している必要があります。
静的メソッドはコピーされないため、新しく作成したHOC内に静的メソッドを含める場合は、自分でコピーする必要があります。
言及された参照渡されないため、React.forwardRefを使用しますそのような問題を解決するために前述したように。

export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log('Very Important Function'); }; render() { return ( ); } }; }

スタイリング

スタイリングは必ずしもReact自体に関連しているわけではありませんが、いくつかの理由から言及する価値があります。

まず、通常のCSS /インラインスタイルが通常どおりここに適用され、CSSからclassName属性にクラス名を追加するだけで、正しく機能します。インラインスタイルは、通常のHTMLスタイルとは少し異なります。文字列はスタイルではなく、それぞれに正しい値を持つオブジェクトで渡されます。スタイル属性もcamelCasedであるため、border-radiusはborderRadiusになります。

Reactは、最近CRAに統合されたCSSモジュールなど、Reactだけでなく一般的になったいくつかのソリューションを普及させたようです。ここでは、name.modules.cssを簡単にインポートできます。プロパティなどのクラスを使用してコンポーネントのスタイルを設定します（WebStormなどの一部のIDEには、使用可能な名前を示すオートコンプリートもあります）。

Reactでも人気のある別のソリューションはCSS-in-JSです（例： emotion 図書館）。もう一度指摘しておきますが、CSSモジュールと感情（または一般的にはCSS-in-JS）は 無制限 反応する。

Reactのフック

フック おそらく、書き直し以来、Reactへの最も待望の追加です。製品は誇大宣伝に応えていますか？私の観点からは、そうです、それらは本当に素晴らしい機能です。これらは本質的に、次のような新しい機会を開く機能です。

多くのclassを削除できますローカル状態や参照など、取得できなかったためにのみ使用したコンポーネント。そのため、コンポーネントのコードは読みやすくなります。
同じ効果のために使用するコードを減らすことができます。
たとえば、を使用して、関数の検討とテストを簡単にします。 react-testing-library 。
パラメータを取ることもでき、その結果を別のフックで簡単に使用できます（たとえば、setStateのuseStateからuseEffect）。
ミニファイアにとって少し問題が多い傾向があるクラスよりもはるかに優れたミニファイを行います。
他の人を解決するように設計されているにもかかわらず、新しい問題を引き起こしたアプリのHOCを削除し、小道具のパターンをレンダリングする可能性があります。
熟練した人なら誰でもカスタムビルドできます React開発者。

デフォルトで含まれているReactフックはほとんどありません。基本的な3つは、useState、useEffect、およびuseContextです。追加のものもいくつかあります。例：useRefおよびuseMemoですが、ここでは基本に焦点を当てます。

useStateを見て、それを使用して簡単なカウンターの例を作成しましょう。それはどのように機能しますか？基本的に、全体の構成は非常に単純で、次のようになります。

export function Counter() { const [counter, setCounter] = React.useState(0); return ( {counter} setCounter(counter + 1)}>+ ); };

initialStateで呼び出されます（値）そして、2つの要素を含む配列を返します。配列分解割り当てのおかげで、これらの要素に変数をすぐに割り当てることができます。最初の状態は常に更新後の最後の状態であり、もう1つの状態は値を更新するために使用する関数です。簡単そうですね。

また、このようなコンポーネントは以前はステートレス機能コンポーネントと呼ばれていたため、上記のような状態になる可能性があるため、このような名前は適切ではなくなりました。したがって、名前 クラスコンポーネント そして 機能コンポーネント 少なくとも16.8.0からは、彼らが実際に行っていることとより一致しているようです。

更新関数（この場合はsetCounter）は、前の値を引数として次の形式で受け取る関数としても使用できます。

setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>-

ただし、this.setStateとは異なり浅いマージを行っていたクラスコンポーネントで、関数（この場合はsetCounter）を設定すると、代わりに状態全体がオーバーライドされます。

さらに、initialState単なる値ではなく、関数にすることもできます。これには独自の利点があります。この関数はコンポーネントの最初のレンダリング中にのみ実行され、その後は呼び出されなくなります。

const [counter, setCounter] = useState(() => calculateComplexInitialValue());

最後に、setCounterを使用する場合現在の状態（counter）で同じ瞬間に持っていたのとまったく同じ値で、次にコンポーネント しない 再レンダリングします。

一方、useEffectサブスクリプション、API呼び出し、タイマーなど、機能コンポーネントに副作用を追加することです。 useEffectに渡す関数はレンダリング後に実行され、関数の2番目の引数として再実行する必要があるプロパティの変更に関する制限を追加しない限り、すべてのレンダリングの後に実行されます。マウント時にのみ実行し、アンマウント時にクリーンアップする場合は、空の配列を渡すだけです。

const fetchApi = async () => { const value = await fetch('https://jsonplaceholder.typicode.com/todos/1'); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( {counter} setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>- ); };

上記のコードは、2番目の引数として配列が空であるため、1回だけ実行されます。基本的にはcomponentDidMountのようなものですそのような場合、しかしそれは少し後で発火します。ブラウザのペイントの前に呼び出される同様のフックが必要な場合は、useLayoutEffectを使用しますが、useEffectとは異なり、これらの更新は同期的に適用されます。

useContextアクセスしたいコンテキスト（createContext関数によって返されたオブジェクト）を提供し、その代わりに、そのコンテキストの値を提供するため、最も理解しやすいようです。

const context = useContext(Context);

最後に、独自のフックを作成するには、次のように作成します。

function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; }

基本的に、通常のuseStateを使用しています。初期値ウィンドウ幅として割り当てているフック。次にuseEffect,でhandleResizeをトリガーするリスナーを追加しています各ウィンドウのサイズを変更します。コンポーネントがアンマウントされた後もクリアします（useEffectのリターンを見てください）。簡単ですか？

注意： 言葉 使用する すべてのフックで重要です。これは、通常のJS関数からフックを呼び出すなど、Reactが何か悪いことをしていないかどうかを確認できるために使用されます。

タイプの確認

FlowとTypeScriptがオプションになる前は、Reactには独自の小道具チェックがありました。

PropTypesは、Reactコンポーネントによって受信されたプロパティ（小道具）がチェックされ、それらが私たちが持っているものと一致しているかどうかをチェックします。別の状況（配列ではなくオブジェクトなど）が発生すると、コンソールに警告が表示されます。 PropTypeは、パフォーマンスへの影響と前述のコンソール警告のため、開発モードでのみチェックされることに注意することが重要です。

React 15.5の時点で、PropTypesは別のパッケージに含まれており、個別にインストールする必要があります。それらは、propTypesと呼ばれる静的プロパティのプロパティに沿って宣言されます。（驚き）、それらをdefaultPropsと組み合わせますプロパティが定義されていない場合に使用されます（ 未定義 唯一のケースです）。 DefaultPropsはPropTypesとは関係ありませんが、PropTypesが原因で表示される可能性のあるいくつかの警告を解決できます。

C ++の使い方

他の2つのオプションはFlowとTypeScriptであり、最近でははるかに人気があります（特にTypeScript）。

TypeScript は、Microsoftによって開発されたJavaScriptの型付きスーパーセットであり、アプリが実行される前にエラーをチェックでき、開発用の優れたオートコンプリート機能を提供します。また、リファクタリングも大幅に改善されます。型付き言語の豊富な経験を持つMicrosoftのサポートにより、これもかなり安全な選択です。
フロー TypeScriptとは異なり、は言語ではありません。これはJavaScriptの静的型チェッカーであるため、言語というよりもJavaScriptに含めるツールに似ています。 Flowの背後にある全体的な考え方は、TypeScriptが提供するものと非常に似ています。これにより、型を追加できるため、コードを実行する前にバグが発生する可能性が低くなります。 TypeScriptと同様に、フローは最初からCRA（Create React App）でサポートされるようになりました。

個人的には、TypeScriptの方が速く（実際には瞬時に）、特にオートコンプリートでは、Flowでは少し遅いように見えます。私が個人的に使用しているWebStormなどのIDEは、Flowとの統合にCLIを採用していることに注意してください。ただし、オプションの使用をファイルに統合する方がさらに簡単なようです。ここでは、// @flowを追加するだけです。ファイルの先頭でタイプチェックを開始します。また、私が知る限り、TypeScriptは最終的にFlowとの戦いに勝ったようです。現在でははるかに人気があり、最も人気のあるライブラリのいくつかはFlowからTypeScriptにリファクタリングされています。

Reason（Facebookによって開発され、Reactコミュニティで人気を博している）、Kotlin（JetBrainsによって開発された言語）など、公式ドキュメントにも記載されているオプションがいくつかあります。

明らかに、フロントエンド開発者にとって最も簡単なアプローチは、KotlinまたはF＃に切り替えるのではなく、フローとTypeScriptを使用して開始することです。ただし、フロントエンドに移行するバックエンド開発者にとって、これらは実際には使い始めるのが簡単な場合があります。

生産と反応性能

本番モードで行う必要がある最も基本的で明白な変更は、DefinePluginの「本番」に切り替えることです。そしてUglifyJsPluginを追加しますWebpackの場合。 CRAの場合、npm run buildを使用するのと同じくらい簡単です。（これはreact-scripts buildを実行します）。 Brunchなどの他のビルドツールを使用できるため、WebpackとCRAだけがオプションではないことに注意してください。これは通常、公式のReactドキュメントであれ、特定のツールのドキュメントであれ、公式のドキュメントでカバーされています。モードが正しく設定されていることを確認するには、次を使用できます React開発者ツール、これにより、使用しているビルドの種類（本番環境と開発環境）がわかります。前述の手順により、Reactからのチェックや警告なしでアプリケーションが実行され、バンドル自体も最小化されます。

Reactアプリでできることは他にもいくつかあります。作成されたJSファイルをどうしますか？サイズが比較的小さい場合は「bundle.js」から始めるか、「ベンダー+バンドル」または「ベンダー+必要最小限のパーツ+必要なときにインポートする」などの操作を行うことができます。これは、非常に大きなアプリを扱っていて、最初からすべてをインポートする必要がない場合に便利です。使用されていないJavaScriptコードをメインバンドルにバンドルすると、バンドルサイズが大きくなり、最初はアプリの読み込みが遅くなることに注意してください。

ベンダーバンドルは、ライブラリのバージョンが長期間変更されない可能性があることに気付いたときに、ライブラリのバージョンを凍結することを計画している場合に役立ちます。また、ファイルが大きいほどgzipが優れているため、分離することで得られるメリットが価値がない場合があります。ファイルサイズによって異なりますが、自分で試してみる必要がある場合もあります。

コード分割

コード分割は、ここで提案されているよりも多くの方法で表示される可能性がありますが、CRAとReact自体で利用できるものに焦点を当てましょう。基本的に、コードを異なるチャンクに分割するために、import()を使用できます。これはWebpackのおかげで機能します（import自体は現在ステージ3での提案であるため、まだ言語標準の一部ではありません）。 Webpackがimportを検出すると、この段階でコード分割を開始する必要があり、メインバンドル（インポート内にあるコード）に含めることができないことがわかります。

これで、React.lazy()に接続できますimport()が必要ですその場所でレンダリングする必要のあるコンポーネントを含むファイルパスを使用します。次に、React.suspense()を使用できますインポートされたコンポーネントがロードされるまで、その場所に別のコンポーネントが表示されます。不思議に思うかもしれません。単一のコンポーネントをインポートする場合、なぜそれが必要になるのでしょうか。

React.lazy()のように、そうではありません。 import()のコンポーネントが表示されますが、import()その単一のコンポーネントよりも大きなチャンクをフェッチする可能性があります。たとえば、その特定のコンポーネントに他のライブラリが含まれている場合や、コードが多い場合など、1つのファイルは必要ありません。さらに多くのファイルがバンドルされている場合があります。最後に、それらすべてをErrorBoundaryでラップできます。 （エラー境界に関するセクションでコードを見つけることができます） これは、インポートしたいコンポーネントで何かが失敗した場合のフォールバックとして機能します（たとえば、ネットワークエラーがある場合）。

import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return (  ); }

これは基本的な例ですが、明らかにもっと多くのことができます。 importを使用できますおよびReact.lazy動的ルート分割の場合（たとえば、管理者と通常のユーザー、または多くをもたらす非常に大きなパス）。 React.lazyに注意してください現在のところ、デフォルトのエクスポートのみをサポートしており、サーバー側のレンダリングはサポートしていません。

Reactコードのパフォーマンス

パフォーマンスに関しては、Reactアプリケーションの動作が遅い場合、問題を理解するのに役立つ2つのツールがあります。

最初のものは Chromeの[パフォーマンス]タブ、各コンポーネントで何が起こるかを教えてくれます（マウント、アップデートなど）。そのおかげで、どのコンポーネントがパフォーマンスの問題の問題を示しているかを特定し、それを最適化できるはずです。

他のオプションは使用することです DevToolsプロファイラーこれはReact16.5 +で利用可能になり、shouldComponentUpdate（またはPureComponentで説明されています。このチュートリアルのパート1 ）、いくつかの重要なコンポーネントのパフォーマンスを向上させることができます。

明らかに、一部のイベントのデバウンス（スクロールなど）、アニメーションの慎重さ（高さを変更してアニメーション化する代わりに変換を使用）など、Webの基本的なベストプラクティスを採用することが最適です。ベストプラクティスの使用は、特にReactを理解し始めたばかりの場合は、非常に簡単に見落とされる可能性があります。

2019年以降の反応の状態

Reactの将来について個人的に話し合うのであれば、私はあまり心配しません。私の見解では、Reactは2019年以降もその王位を維持するのに問題はありません。

Reactは非常に強力な立場にあり、大規模なコミュニティの支持を得ているため、王位を奪うことは困難です。 Reactコミュニティは素晴らしく、アイデアが不足することはありません。コアチームは、Reactの改善、新機能の追加、古い問題の修正に絶えず取り組んでいます。 Reactも巨大企業に支えられていますが、ライセンスの問題はなくなりました。現在MITライセンスです。

はい、変更または改善が期待されることがいくつかあります。たとえば、Reactを少し小さくする（言及された手段の1つは合成イベントを削除することです）、または名前を変更するclassName 〜class.もちろん、これらの一見小さな変更でさえ、ブラウザの互換性に影響を与えるなどの問題を引き起こす可能性があります。個人的には、WebComponentの人気が高まるとどうなるのだろうかと思います。これは、Reactが今日よく使用されているもののいくつかを補強する可能性があるためです。それらが完全に置き換わるものになるとは思いませんが、互いにうまく補完し合う可能性があると思います。

短期的には、フックがReactに来たばかりです。これは、Reactで書き換えが行われて以来、おそらく最大の変更です。多くの可能性が開かれ、さらに機能コンポーネントが強化されるためです（そして、現在、実際に誇大宣伝されています）。

最後に、それが私が最近やっていることなので、リアクトネイティブ。私にとって、これは過去2年間で大きく変化した優れたテクノロジーです（react-nativeリンクの欠如は、おそらくほとんどの人にとって最大の問題であり、明らかに多くのバグがありました）。 React Nativeはコアを書き換えています。これは、Reactの書き換えと同様の方法で行う必要があります（これはすべて内部的なものであり、開発者にとっては何も変更しないでください）。非同期レンダリング、ネイティブとJavaScriptの間のより高速で軽量なブリッジなど。