私の主な指導課題の1つは、人々に洞察の瞬間を与えやすくすることです。 「交響詩！エウレカ！」は、以前は理解できなかった事実が突然意味をなすとき、突然の明確化の瞬間です。 これは皆に起こりました。 私は多くの教師に精通しており、最高の教師は生徒のインスピレーションがより頻繁に生じるようにレッスンを行うことができます。
過去数年間、私はReactにあらゆる方法を教えてきました。 この間、私はそのような「エウレカ！」モーメントを引き起こすものについて詳細なメモを作成しました。
私は最近、同じ考えが議論されていたRedditブランチにつまずきました。 議論は私にこの記事を書くきっかけとなり、そこで私は主要な学習の洞察を共有しました。 Reactを使用する際の原則を再確認するのに役立つことを願っています。
インスピレーション番号1。 コンポーネントの小道具-関数の引数と同じ
Reactの利点：JavaScript関数に使用するのと同じ直感を使用して、Reactコンポーネントをいつどこで作成するかを理解できます。 Reactの違いは次のとおりです。いくつかの引数を取り値を返す代わりに、関数はいくつかの引数を取り、 ユーザーインターフェイス（UI）のオブジェクト表現を返します。
このアイデアは、式fn（d）= Vで表すことができます。「関数はデータを取り、表現を返します」と読みます。
これは、ユーザーインターフェイスの開発を想像するのに最適な方法です。現在、UIは単純にさまざまな関数呼び出しで構成されています。 それはアプリケーションを構築するようなものです。 ユーザーインターフェイスを作成するときに、機能の構成を最大限に活用できるようになりました。
インスピレーション番号2。 Reactでは、アプリケーションのユーザーインターフェイスは機能構成を使用して完全に構築されます。 JSXはこれらの機能の抽象化です
Reactを初めて使用する人に最もよく見られる反応は、次のようなものです。「Reactはクールですが、JSXは私の好みではありません。 責任分担を破壊します。」 JSXはHTMLになろうとはしていません。 そして、それは間違いなく単なるテンプレート言語以上のものです。 JSXについて理解する必要がある2つの重要なことがあります。
まず、JSXはDOMのオブジェクト表現を返す関数であるReact.createElementの抽象化です。
JSXをブロードキャストするときはいつでも、実際のDOMを表すJavaScriptオブジェクト、または現在使用しているプラットフォーム（iOS、Androidなど）のその他の表現があります。 次に、Reactはこのオブジェクトを解析し、実際のDOMを解析します。 diffを使用すると、Reactは変更が発生したDOMのみを更新できます。 これによりパフォーマンスが向上しますが、さらに重要なことは、JSXが実際には「単なるJavaScript」であることを示しています。
第二に、JSXは単なるJavaScriptであるため、JavaScriptのすべての利点（構成、リント、デバッグなど）を利用できます。 しかし、あなたはまだ宣言的でHTMLに似ています。
インスピレーション番号3。 コンポーネントはDOMノードと一致する必要はありません
Reactを初めて理解すると、「コンポーネントはReactの構成要素である」ということがわかります。 「彼らは入力を受け取り、何らかのインターフェイス（ハンドルテンプレート）を返します。」
これは、通常学習するように、各コンポーネントがユーザーインターフェイスハンドルを直接返す必要があることを意味しますか？ コンポーネントに別のコンポーネント（高次コンポーネントテンプレート）を表示させたい場合はどうでしょうか？ コンポーネントが状態の特定のセクションを制御し、ユーザーインターフェイスハンドルを返す代わりに状態で関数呼び出しを返すようにしたい場合（Render Propsテンプレート） そして、ビジュアルインターフェイスではなく、サウンドの管理を担当するコンポーネントがある場合、それは何を返しますか？
Reactの良い点は、コンポーネントから典型的な「ビュー」を返す必要がないことです。 結果がReact要素（nullまたはfalse）を返す限り、すべて正常です。
さまざまなコンポーネントを返すことができます。
render () { return } You can return function invocations: render () { return this.props.children(this.someImportantState) } Or you can return nothing at all: render () { return null }
インスピレーション番号4。 2つのコンポーネントが状態を分離する必要がある場合、同期せずに上げる必要があります
コンポーネントアーキテクチャは、もちろん、状態の分離を複雑にします。 2つのコンポーネントが同じ状態に依存している場合、どこにあるべきですか？ これは非常に一般的な質問であり、ソリューションのエコシステム全体の出現を引き起こし、最終的にReduxが登場しました。
Reduxのソリューションは、この一般的な状態をリポジトリと呼ばれる別の場所に置くことです。 コンポーネントは、リポジトリの必要な部分をサブスクライブでき、「アクション」を送信してリポジトリを更新することもできます。
Reactソリューションは、これらの両方のコンポーネントに最も近い親を見つけ、その親に強制的に共有状態を管理させ、必要に応じて子コンポーネントに渡します。 どちらのアプローチにも長所と短所がありますが、両方のソリューションが存在することを知っておくことが重要です。
インスピレーション番号5。 Reactでは継承は不要であり、コンポジションを使用して封じ込めと特化を取得できます。
幸いなことに、Reactは関数型プログラミングの原則に関して常に非常に自由に考えています。 Reactの継承から構成への移行の一例は、ReactがES6クラスでMixinsサポートを追加しなかったことが明らかになったリリース0.13です。
その理由は、Mixinsや継承でできることはほぼすべて、合成によってもできるが、副作用は少ないからです。 継承のメンタリティを持ってReactに来た場合、新しい考え方は難しく、珍しいものになる可能性があります。
インスピレーション番号6。 コンテナとプレゼンテーションコンポーネントの分離
Reactコンポーネントの構造に注意を払うと、通常、状態、ライフサイクルフック、JSXによるマークアップが含まれます。
このすべてを1つのコンポーネントに入れる代わりに、状態フックとライフサイクルフックをマークアップから分離できたらどうでしょうか。 2つのコンポーネントを取得します。 最初のものには、状態、ライフサイクルメソッドが含まれ、コンポーネントの動作方法を担当します。 2番目は小道具を介してデータを受け取り、コンポーネントの外観に責任を負います。
このアプローチにより、プレゼンテーションコンポーネントは受信データと関連付けられなくなるため、プレゼンテーションコンポーネントをより効果的に再利用できます。
また、あなたとあなたのプロジェクトを掘り下げる人が、アプリケーションの構造をよりよく理解できることもわかりました。 ユーザーインターフェイスを見たり心配したりすることなく、コンポーネントの実装を置き換えることができます。 その結果、開発者は、プレゼンテーションコンポーネントがデータを受信する方法を心配することなく、ユーザーインターフェイスをカスタマイズできます。
インスピレーション番号7。 ほとんどのコンポーネントを純粋に保とうとすると、ステートレス要素を維持するのがはるかに簡単になります。
これは、プレゼンテーションコンポーネントをコンテナのコンポーネントから分離するもう1つの利点です。 状態は矛盾の仲間です。 正しい分離線を定義することにより、複雑さをカプセル化することにより、アプリケーションの予測可能性を大幅に改善できます。
私の記事を読んでくれてありがとう！
編集者から
JavaScriptを深く学ぶことは、長い道のりです。 また、Reactライブラリは、本格的なフロントエンド開発者の履歴書の多くのポイントの1つにすぎず、最初の開発者からはほど遠いものです。
JavaScriptの知識にWeb APIの深い理解を加えたい場合、純粋なJavaScriptの問題を解決する方法を学び、BOMとDOMを理解し、非同期HTTPリクエスト（AJAX）とWebソケット（WebSocket）を学びます-上級コース「Front-開発の終了：インタラクティブなWebページの作成 。 」