なぜそれはアンチパターンなのですか？

こんにちは。9月には、JS開発に関するいくつかのコースがOTUSで同時に開始されます。つまり、JavaScriptDeveloperです。プロフェッショナル、JavaScript開発者。BasicおよびReact.js開発者。これらのコースの開始を見越して、別の興味深い翻訳を用意しました。また、次のトピックに関する無料のデモレッスンにサインアップすることもできます。

• React + Storybookでのコンポーネントライブラリの開発
• JSでのテスト主導の開発または愛情のあるプログラミングを開始する方法
• 実際のプロジェクトをJavascriptからTypescriptに移行する-苦痛と機能

それでは、記事に移りましょう。

---

Reactを学び始めたとき、理解できないことがいくつかありました。そして、Reactに精通しているほとんどの人が同じ質問をしていると思います。人々は差し迫った問題を解決するためにライブラリ全体を構築しているので、私はこれを確信しています。ほとんどすべてのReact開発者が気にかけていると思われる2つの主な質問を次に示し



ます。あるコンポーネントが別のコンポーネントにある情報（特に状態変数）にどのようにアクセスするか。あるコンポーネントが別のコンポーネントにある関数をどのように呼び出すのですか？



一般的なJavaScript開発者（特にReact開発者）は、最近、いわゆる純粋な関数の作成にますます関心を寄せています。状態変化に関連付けられていない関数。外部データベース接続を必要としない機能。それらの外部で何が起こるかに依存しない機能。



もちろん、純粋な機能は高貴な目標です。しかし、多かれ少なかれ複雑なアプリケーションを開発している場合、すべての機能をクリーンにすることはできません。確かに、他のコンポーネントに何らかの形で関連するコンポーネントを少なくともいくつか作成する必要があるときが来るでしょう。これを避けようとするのはばかげています。コンポーネント間のこれらの接続は、依存関係と呼ばれます。



一般に、依存関係は悪く、本当に必要な場合にのみ使用するのが最適です。しかし、繰り返しになりますが、アプリケーションが成長した場合、そのコンポーネントの一部は必然的に相互に依存します。もちろん、React開発者はこれを知っているので、1つのコンポーネントに重要な情報または機能をその子コンポーネントに渡す方法を考え出しました。

標準的なアプローチ：小道具を使用して値を渡す

任意の状態値は、小道具を介して別のコンポーネントに渡すことができます。すべての関数は、すべて同じ小道具を介して子コンポーネントに渡すことができます。これは、子孫がツリーに格納されている状態値を認識し、親コンポーネントでアクションを呼び出す可能性がある方法です。もちろん、これはすべて良いことです。しかし、Reactの開発者は特定の問題を懸念しています。



ほとんどのアプリケーションは階層化されています。複雑なアプリケーションでは、構造を非常に深くネストできます。一般的なアーキテクチャは次のようになります。



App→参照ContentArea

ContentArea→→参照MainContentArea

MainContentArea→→参照MyDashboard

MyDashboard→→参照MyOpenTickets

MyOpenTickets→→参照TicketTable

TicketTable→→参照シーケンス→TicketRow

全員TicketRow→参照→TicketDetail



理論的には、この花輪は長い間巻き付けることができます。すべてのコンポーネントは全体の一部です。より正確には、階層の一部です。しかし、ここで疑問が生じます：上記の例



のコンポーネントTicketDetailは、に格納されている状態値を読み取ることができContentAreaますか？または。コンポーネントTicketDetailはにある関数を呼び出すことができますContentAreaか？

両方の質問に対する答えはイエスです。理論的には、すべての子孫は、親コンポーネントに格納されているすべての変数について知ることができます。また、祖先関数を呼び出すこともできますが、大きな注意点があります。これは、そのような値（状態または関数の値）が小道具を介して子孫に明示的に渡される場合にのみ可能です。そうしないと、コンポーネントの状態または関数の値をその子コンポーネントで使用できなくなります。



小さなアプリケーションやユーティリティでは、これは特別な役割を果たしません。たとえば、コンポーネントTicketDetailがに格納されている状態変数にアクセスする必要がある場合TicketRow、コンポーネントにTicketRow→これらの値をその子孫に渡す→ TicketDetail1つ以上の小道具を介して行うだけで十分です。コンポーネントTicketDetailがにある関数を呼び出す必要がある場合も同じですTicketRow。コンポーネントTicketRow→この関数をその子孫→ TicketDetailprop経由で渡します。ツリーのはるか下にあるコンポーネントが、階層の最上位にあるコンポーネントの状態または機能にアクセスする必要があるときに、問題が発生します。



この問題を解決するために、Reactは伝統的にすべてのレベルに変数と関数を渡してきました。しかし、これはコードを乱雑にし、リソースを消費し、真剣な計画を必要とします。私たちは、このような多くのレベルに値を渡す必要があります：



ContentArea→ MainContentArea→ MyDashboard→ MyOpenTickets→ TicketTable→ TicketRow→TicketDetail



されていることから、状態変数を渡すためにContentAreaとTicketDetail、私たちは多くの作業を行う必要があります。経験豊富な開発者は、値を渡すという醜い長いチェーンがあり、コンポーネントの中間レベルを介して小道具として機能することを理解しています。解決策は非常に面倒なので、Reactの学習を何度かあきらめました。

Reduxという名前のモンスター

すべての状態値とコンポーネントに共通のすべての関数 を小道具を介して渡すことは非常に非現実的であると考えるのは私だけではありません。状態管理ツールが付属していない複雑なReactアプリケーションが見つかる可能性はほとんどありません。そのようなツールはそれほど少なくありません。個人的にはMobXが大好きです。残念ながら、Reduxは「業界標準」と見なされています。



Reduxは、Reactコアの作成者の発案によるものです。つまり、彼らは最初に素晴らしいReactライブラリを作成しました。しかし、彼らはすぐに彼女の手段で国家を管理することはほとんど不可能であることに気づきました。もし彼らがこの（そうでなければ素晴らしい）ライブラリの固有の問題を解決する方法を見つけなかったら、私たちの多くはReactについて聞いたことがなかっただろう。



そこで彼らはReduxを思いついた。

ReactがMonaLisaの場合、Reduxはそれに付随する口ひげです。 Reduxを使用している場合は、ほぼすべてのプロジェクトファイルに大量の定型コードを記述する必要があります。トラブルシューティングとコードの読み取りは地獄になります。ビジネスロジックは裏庭に持ち出されます。コードには混乱と揺れが含まれています。



ただし、開発者がReact + Reduxまたはサードパーティの状態管理ツールを使用せずにReactを選択できる場合、ほとんどの場合、React + Reduxを選択します。 ReduxライブラリはReactコアの作成者によって開発されたため、デフォルトで承認されたソリューションと見なされます。そして、ほとんどの開発者は、このように暗黙のうちに承認されたソリューションを使用することを好みます。



もちろん、Reduxは依存関係のウェブ全体を作成しますReactアプリケーションで。しかし、公平を期すために、一般的な状態管理ツールでも同じことができます。状態管理ツールは、変数と関数の共有リポジトリです。このような関数と変数は、共有ストレージにアクセスできるすべてのコンポーネントで使用できます。これには明らかな欠点が1つあります。それは、すべてのコンポーネントが共有ストレージに依存するようになることです。



Reduxの使用に抵抗しようとした私が知っているReact開発者のほとんどは、最終的にあきらめました。 （なぜなら...抵抗は役に立たないからです。）私はすぐにReduxを嫌う多くの人々を知っています。しかし、彼らが選択に直面したとき-Reduxまたは「別のReact開発者を見つける」-彼らは自分自身を投げました彼らの生活の不可欠な部分としてReduxを受け入れることに同意しました。それは税金のようなものです。直腸検査のように。歯科医に行くように。

Reactで共有値を反応させる

私は頑固すぎて簡単に諦めません。Reduxを見た後、私は他の解決策を探す必要があることに気づきました。私がすることができますReduxのを使用しています。そして、私はこのライブラリを使用するチームで働きました。一般的に、私は彼女が何をしているのか理解しています。しかし、それは私がReduxが好きだという意味ではありません。

私が言ったように、別個の状態管理ツールが不可欠ですが、MobXはReduxよりも約... 100万倍優れています！しかし、私はもっと深刻な質問に苦しんでいます。それはReact開発者の集合的な心に触れ



ます：なぜ私たちは常に最初に状態管理ツールをつかむのですか？



Reactで最初に開発を始めたとき、私は代替ソリューションを探すために多くの夜を過ごしました。そして、私は多くのReact開発者が無視する方法を見つけましたが、誰もその理由を知ることができません。説明します。



上で書いた架空のアプリケーションで、次のようなファイルを作成するとします。

// components.js
let components = {};
export default components;

そしてそれがすべてです。たった2行の短いコード。空のオブジェクト（古き良きJSオブジェクト）を作成します。デフォルトではexport default。を使用してエクスポートします。



次に、コンポーネント内のコードがどのように見えるかを見てみましょう<ContentArea>。

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      components.ContentArea = this;
   }

   consoleLog(value) {
      console.log(value);
   }

   render() {
      return <MainContentArea/>;
   }
}

ほとんどの場合、これは完全に通常のクラスベースのReactコンポーネントのように見えます。render()ツリーの次のコンポーネントにアクセスする単純な関数があります。console.log()コード実行の結果をコンソールに出力する小さな関数と、コンストラクターがあります。しかし...コンストラクターにはいくつかのニュアンスがあります。



最初に、単純なオブジェクトをインポートしましたcomponents。次に、コンストラクターcomponentsで、現在のReactコンポーネント（this）の名前でオブジェクトに新しいプロパティを追加しました。このプロパティでは、コンポーネントを参照しますthis。これで、コンポーネントオブジェクトにアクセスするたびに、コンポーネントに直接アクセスできるようになります<ContentArea>。



階層の最下部で何が起こるか見てみましょう。コンポーネント<TicketDetail>は次のようになります。

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      components.ContentArea.consoleLog('it works');
      return <div>Here are the ticket details.</div>;
   }
}

これが何が起こるかです。コンポーネントTicketDetailがレンダリングされるたびに、コンポーネントにconsoleLog()格納されている関数が呼び出されContentAreaます。関数は、小道具を介して階層全体に渡されるわけではないことに



注意してくださいconsoleLog()。実際、関数はconsoleLog()どこにも、どこにも、どのコンポーネントにも渡されません。



それでも、2つのことを行ったため、に格納されてTicketDetailいる関数consoleLog()を呼び出すことができますContentArea。

1. ContentAreaロードされると、コンポーネントはそれ自体へのリンクをコンポーネント共有オブジェクトに追加しました。
2. TicketDetailロードされると、コンポーネントは共有オブジェクトをインポートしましたcomponents。つまり、プロパティが小道具を介してコンポーネントに渡されなかったにもかかわらず、コンポーネントに直接アクセスできました。ContentAreaContentAreaTicketDetail

このアプローチは、関数/コールバックでのみ機能するわけではありません。状態変数の値を直接照会するために使用できます。<ContentArea>このように見えるものを想像してみましょう：

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   render() {
      return <MainContentArea/>;
   }
}

次に、次の<TicketDetail>ように書くことができます。

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return <div>Here are the ticket details.</div>;
   }
}

さて、コンポーネントが描画されるたびに<TicketDetail、それは変数の値を探しますstate.reduxSucksの中で<ContentArea>。変数が値を返す場合、true関数console.log()はコンソールにメッセージを出力します。これは、変数の値がContentArea.state.reduxSucks小道具を介してツリーから（いずれかのコンポーネントに）渡されたことがない場合でも発生します。したがって、標準のReactライフサイクルの外にある1つの単純な基になるJSオブジェクトを使用して、コンポーネントオブジェクトにロードされた親から子孫が状態変数を直接読み取ることができるようにすることができます。親コンポーネントの関数をその子孫で呼び出すこともできます。



子コンポーネントで関数を直接呼び出すことができるということは、親コンポーネントの状態を子から直接変更できることを意味します。たとえば、このように。



まず、コンポーネント<ContentArea>で、変数の値を変更する単純な関数を作成しますreduxSucks。

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
   }

   render() {
      return <MainContentArea/>;
   }
}

次に、コンポーネントで<TicketDetail>、オブジェクトを介してこのメ​​ソッドを呼び出しますcomponents。

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

これで、コンポーネントをレンダリングするたびに、<TicketDetail>ユーザーはボタンを押すことができます。ボタンを押すとContentArea.state.reduxSucks、関数ContentArea.toggleReduxSucks()が小道具を介してツリーに渡されたことがない場合でも、変数の値をリアルタイムで変更（切り替え）できます。



このアプローチでは、親コンポーネントはその子から直接関数を呼び出すことができます。これがその方法です。更新されたコンポーネント<ContentArea>は次のようになります。

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
      components.TicketTable.incrementReduxSucksHasBeenToggledXTimes();
   }

   render() {
      return <MainContentArea/>;
   }
}

次に、コンポーネントにロジックを追加しましょう<TicketTable>。このような：

// ticket.table.js
import components from './components';
import React from 'react';
import TicketRow from './ticket.row';

export default class TicketTable extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucksHasBeenToggledXTimes: 0 };
      components.TicketTable = this;
   }

   incrementReduxSucksHasBeenToggledXTimes() {
      this.setState((previousState, props) => {
         return { reduxSucksHasBeenToggledXTimes: previousState.reduxSucksHasBeenToggledXTimes + 1};
      });      
   }

   render() {
      const {reduxSucksHasBeenToggledXTimes} = this.state;
      return (
         <>
            <div>The `reduxSucks` value has been toggled {reduxSucksHasBeenToggledXTimes} times</div>
            <TicketRow data={dataForTicket1}/>
            <TicketRow data={dataForTicket2}/>
            <TicketRow data={dataForTicket3}/>
         </>
      );
   }
}

その結果、コンポーネントは<TicketDetail>変更されていません。それはまだこのように見えます：

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

これらの3つのクラスに関連する奇妙なことに気づきましたか？アプリケーションの階層でContentAreaは、これはの親コンポーネントTicketTableであり、はの親コンポーネントですTicketDetail。私たちは部品を実装する場合、この手段ContentArea、それはまだその存在を「知らない」TicketTable。そして機能toggleReduxSucks()で書かれたが、ContentArea暗黙のうちに子関数を呼び出す:.それは

incrementReduxSucksHasBeenToggledXTimes()ことが判明したコードは動作しません右、？



しかし、違います。



見て。アプリケーションにいくつかのレベルを作成しましたが、関数を呼び出す方法は1つしかありませんtoggleReduxSucks()。このような。

1. マウントしてレンダリングしますContentArea。
2. このプロセス中に、コンポーネントへの参照がコンポーネントオブジェクトにロードされますContentArea。
3. 結果がマウントされ、レンダリングされますTicketTable。
4. このプロセス中に、コンポーネントへの参照がコンポーネントオブジェクトにロードされますTicketTable。
5. 結果がマウントされ、レンダリングされますTicketDetail。
6. « reduxSucks» (Toggle reduxSucks).
7. « reduxSucks».
8. toggleReduxSucks(), ContentArea.
9. incrementReduxSucksHasBeenToggledXTimes() TicketTable .
10. , , « reduxSucks», TicketTable components. toggleReduxSucks() ContentArea incrementReduxSucksHasBeenToggledXTimes(), TicketTable, components.

アプリケーションの階層により、コンポーネントがマウントされたときにコンポーネントの存在を認識していなかったにもかかわらず、ContentArea子コンポーネントから関数を呼び出すアルゴリズムをコンポーネントに追加できることがわかりました。ContentAreaTicketTable

ウェルスマネジメントツール-ダンプ

私が説明したように、私はReduxがMobXに匹敵しないことを深く確信しています。そして、プロジェクトに最初から取り組む特権を得るとき（残念ながら頻繁ではありません）、私は常にMobXのキャンペーンを行います。Redux用ではありません。しかし、独自のアプリケーションを開発するとき、サードパーティの状態管理ツールを使用することはめったにありません。ほとんど使用しません。代わりに、可能な限りオブジェクト/コンポーネントをキャッシュします。そして、このアプローチが機能しない場合、私はReactのデフォルトのソリューションにフォールバックすることがよくあります。つまり、関数/状態変数を小道具に渡すだけです。

このアプローチの既知の「問題」

基になるオブジェクトをキャッシュするという私の考えが、components共有状態/機能の問題を解決するのに必ずしも適しているとは限らないことを私はよく知っています。時々、このアプローチは...残酷な冗談を言うことができます。または、まったく機能しない可能性があります。ここで覚えておくべきことがあります。

• シングルで最適に動作します。
  
  
  
  たとえば、階層では、<TicketTable>コンポーネントに0対多の関係を持つ<TicketRow>コンポーネントが含まれています。<TicketRow>コンポーネント（およびその子<TicketDetail>コンポーネント）内の各潜在的なコンポーネントへの参照をコンポーネントキャッシュにキャッシュする場合は、それらを配列に格納する必要があり、これは注意が必要です。私はいつもこれを避けてきました。
• components , / , components. .
  
  , . , , . / , , components.
• , components, ( setState()), setState(), .

私のアプローチとその制限のいくつかを説明したので、警告しなければなりません。このアプローチを発見して以来、私は自分たちをプロのReact開発者と見なしている人々と共有してきました。彼らが同じことを答えるたびに：



うーん...そうしないでください。彼らは眉をひそめ、私がただ空気を台無しにしたように振る舞います。私のアプローチの何かが彼らに思えます...間違っています。同時に、彼らの豊富な実務経験に基づいて、正確に何が間違っているのか、まだ誰も私に説明していません。誰もが私のアプローチを検討しているだけです...冒涜。



したがって、このアプローチが気に入った場合や、状況によっては便利だと思った場合でも、お勧めしません。React開発者としての仕事を得たい場合は、インタビューでそれについて話してください。他のReact開発者と話をするだけでも、この方法について話す前に何百万回も考える必要があると思います。あるいは、何も言わないほうがよいかもしれません。



JS開発者（特にReact開発者）は過度に分類的である可能性があることがわかりました。アプローチAが「間違っている」理由とアプローチBが「正しい」理由を説明することもあります。しかし、ほとんどの場合、彼ら自身が理由を説明できない場合でも、コードの一部を見て「悪い」と宣言するだけです。

では、なぜこのアプローチがReact開発者にとってそれほど煩わしいのでしょうか。

私が言ったように、私の同僚の誰も私の方法が悪い理由に合理的に答えることができませんでした。そして、誰かが答えで私を称えることをいとわないなら、それは通常、次の言い訳の1つです（それらのいくつかはありません）。

• , .
  
  
  
  .... , , Redux ( MobX, ) / React-. , . — . , /, . : , components. , / components, / , components. /, components , components . , , . , , Redux, MobX, - .
• React « ». … .
  
  
  
  … . ? , . — - « » « », , , . React, . , . . « », . , React 100 %, ( ) , .

, ?

私はこのアプローチを何年も（個人的なプロジェクトで）使用しているので、この投稿を書きました。そしてそれは素晴らしい働きをします。しかし、私が個人的なバブルから抜け出し、他のサードパーティのReact開発者とこのアプローチについてインテリジェントな会話をしようとするたびに、「業界標準」についての明確な声明と愚かな判断に出くわすだけです。



このアプローチは本当に悪いですか？まあ、本当に。私は知りたいです。これが確かに「反パターン」であるならば、私はその誤りを正当化する人々に非常に感謝します。 「私はこれに慣れていない」という答えは私には合いません。いいえ、私はこの方法に固執していません。これがReact開発者にとって万能薬であることを示唆しているわけではありません。そして、私はそれがすべての状況で機能するとは限らないことを認めます。だけど、たぶん誰かが私にそれの何が問題なのか説明できますか？



私は本当にこの問題についてのあなたの意見を知りたいです-たとえあなたが私を鍛冶屋に吹き飛ばしたとしても。

無料レッスン：

• React + Storybookでのコンポーネントライブラリの開発
• JSでのテスト主導の開発または愛情のあるプログラミングを開始する方法
• 実際のプロジェクトをJavascriptからTypescriptに移行する-苦痛と機能