内部からのmobxの動作とreduxとの比較

まず、mobxは、状態管理ライブラリとして他のライブラリと比較され@observableデコレータ@observableマークされたプロパティが変更@observable後、reactのコンポーネントを呼び出すことを除いて、状態を操作するための利便性をほとんど提供しません。 すべての@observableおよび@observerデコレーターを削除し、動作中のアプリケーションを取得することで、 @observableを簡単に破棄できます。コンポーネントに表示される状態データを変更するすべてのイベントハンドラーの最後にupdate()を1行追加するだけです。

 onCommentChange(e){ const {comment} = this.props; comment.text = e.target.value; update(); //   } 

そしてupdate（）関数は単にreactアプリケーションの「再レンダラー」を呼び出し、reactの仮想運命のおかげで、実際の思考ではdiffの変更のみが適用されます

 function update(){ ReactDOM.render(<App>, document.getElementById('root'); } 

mobxはハンドラー内のupdate() 1行を保存するので、ステートマネージャー全体であると言うのは、いくぶん多すぎます。

つまり、mobxは状態の処理を単純化するライブラリではありません。その主なタスクは何ですか？ その主なタスクは、コンポーネントのポイントごとの更新です。つまり、変更されたデータに依存するコンポーネントのみを更新します。
上記の例では、アプリケーションのデータが変更されるReactDOM.render(<App>, document.getElementById('root'))に、 update()関数でReactDOM.render(<App>, document.getElementById('root'))を呼び出して、アプリケーション全体の「再レンダラー」（仮想思考比較）を実行します。これはパフォーマンスに影響し、大規模なアプリケーションではインターフェースの速度が低下することは避けられません。

そして、この問題は、まさにmobxライブラリとreduxライブラリの一部が解決するものです。

しかし、これら2つのライブラリを考慮せずに、コンポーネントを個別に更新する問題を解決してみましょう。

最初のアプローチは不変性とバイナリ検索を使用することです-各状態の更新がすべての親オブジェクトに対して変更された新しいデータオブジェクトを返す場合（状態に階層構造がある場合）、リンクを前と新しいと比較することでコンポーネントのほぼポイントごとの更新を達成できますデータが変更されていないコンポーネント（newSubtree === oldSubtree）のすべてのサブツリーをステートスキップし、その結果、必要なcomのレンダラーを呼び出してアプリケーションを更新します。 構成要素の数である - onenta n個のデータのみO（ログ（N））の成分と比較。

しかし、免疫的アプローチには、国家との協力に制限を課すいくつかの重大な欠点があります。

最初の欠点は、アプリケーション内のデータオブジェクトのプロパティを取得して更新することができないことです。 状態全体の新しい不変オブジェクトを毎回返す必要があるため、新しいオブジェクトを返し、すべての親オブジェクトと配列を再作成する必要があります。 たとえば、状態オブジェクトにプロジェクトの配列が格納されている場合、各プロジェクトにはタスクの配列が格納され、各タスクにはコメントの配列が格納されます。

 let AppState = { projects: [ {..}, {...}, {name: 'project3', tasts: [ {...}, {...}, {name: 'task3', comments: [ {...}, {...}, {text: 'comment3' } ]} ]} ] } 

コメントオブジェクトのテキストを更新するために、 comment.text = 'new text'実行することはできません-最初にコメントオブジェクトを再作成する必要があります（ comment = {...comment, text: 'updated text'} ）、次にする必要がありますタスクオブジェクトを再作成し、そこから他のコメントへのリンクをコピーし（ task = {...task, tasks: [...task.comments]} ）、プロジェクトオブジェクトを再作成し、そこに他のタスクへのリンクをコピーします（ project = {...project, tasks: [...project.tasks]} ）そして最後に既に状態オブジェクトを再作成し、他のプロジェクトへのリンクもコピーします（ AppStat = {...AppState, projects: [...AppState.projects]} ） 。

2番目の欠点は、ある状態で相互に参照するオブジェクトを保存できないことです。 コンポーネントハンドラーのどこかでタスクが配置されているプロジェクトを取得する必要がある場合、オブジェクトを作成するときに親プロジェクトtask.project = projectへのリンクを単純に割り当てることはできません。不変のアプローチの必要性はタスクだけでなく、プロジェクトのその他のすべてのタスクを更新する必要があるという事実につながります-プロジェクトオブジェクトへのリンクが変更されました。つまり、新しいリンクを割り当てることですべてのタスクを更新する必要があります。 オブジェクト、タスクがコメントを保存されている場合と、我々は、彼らが問題のオブジェクトへの参照が格納されるため、コメントのすべてを再作成するために必要な、と我々はに来るので、再帰的に全体の状態を再作成し、それがひどく遅くなります。

その結果、目的のオブジェクトを転送するたびに高次コンポーネントの小道具を変更するか、オブジェクトを参照する代わりにtask.project = '12345';保存するtask.project = '12345'; そして、識別子によってプロジェクトのハッシュを保存および維持する場所ProjectHash['12345'] = project;

不変性を伴うソリューションには多くの欠点があるため、点ベースのコンポーネント更新の問題を別の方法で解決できるかどうかを考えてみましょう。 アプリケーションのデータを変更する場合、このデータに依存するコンポーネントのみを再レンダリングする必要があります。 依存とはどういう意味ですか？ たとえば、コメントテキストを表示する簡単なコメントコンポーネントがあります

 class Comment extends React.Component { render(){ const {comment} = this.props; return <div>{comment.text}</div> } } 

このコンポーネントはcomment.text依存しており、 comment.textが変更されるたびに更新する必要があります。 ただし、コンポーネントに<div>{comment.parent.text}</div>が表示される場合でも、 .textだけでなく.parentも.parentたびにコンポーネントを更新する必要があり.parent 。 免疫アプローチを適用せずにこの問題を解決できますが、javascriptのgetterおよびsetterの機能を使用します。これは、ポイント更新uiの問題を解決するための2番目のアプローチです。

 Object.defineProperty(comment, 'text', { get(){ console.log('>text getter'); return this._text; }, set(val){ console.log('>text setter'); this._text = val; } }) comment.text; //    >text getter comment.text = 'new text' //    >text setter 

そのため、新しい値が割り当てられるたびに実行される関数をセッターに配置し、このプロパティに依存するコンポーネントのリストのレンダラーを呼び出します。 どのコンポーネントがどのプロパティに依存しているかを調べるには、コンポーネントのrender()関数の開始時に現在のコンポーネントをグローバル変数に割り当てる必要があります。オブジェクトのプロパティのgetterを呼び出すときは、グローバル変数にあるこのプロパティの依存関係リストに現在のコンポーネントを追加する必要があります また、コンポーネントはツリー状に「レンダリング」できるため、前のコンポーネントをこのグローバル変数に戻すことを忘れないでください。

 let CurrentComponent; class Comment extends React.Component { render(){ const prevComponent = CurrentComponent; CurrentComponent = this; const {comment} = this.props; var result = <div>{comment.text}</div> CurrentComponent = prevComponent; return result } } comment._components = []; Object.defineProperty(comment, 'text', { get(){ this._components.push(CurrentComponent); return this._text }, set(val){ this._text = val; this._components.forEach(component => component.setState({})) } }) 

私はあなたがアイデアを得ると思います。 このアプローチでは、各プロパティはその依存コンポーネントの配列を格納し、プロパティが変更されるとそれらが更新されます。

ここで、依存コンポーネントの配列のストレージをデータと混合せず、コードを簡素化するために、そのようなプロパティのロジックをCellクラスに取り出します。これは、類推からわかるように、Excelのセルの原理に非常に似ています-他のセルが現在の式に依存している場合セル、値を変更すると、すべての依存セルが更新されます。

 let CurrentObserver = null; class Cell { constructor(val){ this.value = val; this.reactions = new Set(); //        es6  } get(){ if(CurrentObserver){ this.reactions.add(CurrentObserver); } return this.value; } set(val){ this.value = val; for(const reaction of this.reactions){ reaction.run(); } } unsibscribe(reaction){ this.reactions.delete(reaction); } } 

ただし、式を持つセルの役割は、 Cellクラスから継承するComputedCellクラスによって果たされます（他のセルはこのセルに依存する可能性があるため）。 ComputedCellクラスは、コンストラクターで再計算のための関数（式）と、副作用（ .forceUpdate()コンポーネントの呼び出しなど）を実行するためのオプションの関数を.forceUpdate()ます

 class ComputedCell extends Cell { constructor(computedFn, reactionFn, ){ super(undefined); this.computedFn = computedFn; this.reactionFn = reactionFn; } run(){ const prevObserver = CurrentObserver; CurrentObserver = this; const newValue = this.computedFn(); if(newValue !== this.value){ this.value = newValue; CurrentObserver = null; this.reactionFn(); this.reactions.forEach(r=>r.run()); } CurrentObserver = prevObserver; } } 

そして、ゲッターとセッターを毎回実行しないように、typescriptまたはbabelのデコレーターを使用します。 はい、これはクラスを使用し、リテラルconst newComment = {text: 'comment1'}なくconst comment = new Comment('comment1')を介してオブジェクトを作成する必要性に制限を課しますが、ゲッターとセッターを手動で設定する代わりに、プロパティを便利にマークできます@observable通常のプロパティとしてそれ@observable引き続き使用する方法。

 class Comment { @observable text; constructor(text){ this.text = text; } } function observable(target, key, descriptor){ descriptor.get = function(){ if(!this.__observables) this.__observables = {}; const observable = this.__observables[key]; if (!observable) this.__observables[key] = new Observable() return observable.get(); } descriptor.set = function(val){ if (!this.__observables) this.__observables = {}; const observable = this.__observables[key]; if (!observable) this.__observables[key] = new Observable() observable.set(val); } return descriptor } 

また、コンポーネント内のComputedCellクラスを直接操作しないように、このコードを@observerデコレーターに配置します。これは、 render()メソッドをラップし、最初の呼び出しで計算セルを作成し、 render()メソッドを式および関数として渡しますthis.forceUpdate()はthis.forceUpdate()呼び出しthis.forceUpdate()実際には、 componentWillUnmount()メソッドにサブスクthis.forceUpdate()解除を追加し、リアクションのコンポーネントの正しいラッピングの瞬間を追加する必要がありますが、ここでは理解を容易にするためにこのオプションを残します）

 function observer(Component) { const oldRender = Component.prototype.render; Component.prototype.render = function(){ if (!this._reaction) this._reaction = new ComputedCell(oldRender.bind(this), ()=>this.forceUpdate()); return this._reaction.get(); } } 

として使用します

 @observer class Comment extends React.Component { render(){ const {comment} = this.props; return <div>{comment.text}</div> } } 

デモへのリンク

 import React from 'react'; import { render } from 'react-dom'; let CurrentObserver; class Cell { constructor(val) { this.value = val; this.reactions = new Set(); } get() { if (CurrentObserver) { this.reactions.add(CurrentObserver); } return this.value; } set(val) { this.value = val; for (const reaction of this.reactions) { reaction.run(); } } unsubscribe(reaction) { this.reactions.delete(reaction); } } class ComputedCell extends Cell { constructor(computedFn, reactionFn) { super(); this.computedFn = computedFn; this.reactionFn = reactionFn; this.value = this.track(); } track(){ const prevObserver = CurrentObserver; CurrentObserver = this; const newValue = this.computedFn(); CurrentObserver = prevObserver; return newValue; } run() { const newValue = this.track(); if (newValue !== this.value) { this.value = newValue; CurrentObserver = null; this.reactionFn(); } } } function observable(target, key) { return { get() { if (!this.__observables) this.__observables = {}; let observable = this.__observables[key]; if (!observable) observable = this.__observables[key] = new Cell(); return observable.get(); }, set(val) { if (!this.__observables) this.__observables = {}; let observable = this.__observables[key]; if (!observable) observable = this.__observables[key] = new Cell(); observable.set(val); } } } function observer(Component) { const oldRender = Component.prototype.render; Component.prototype.render = function(){ if (!this._reaction) this._reaction = new ComputedCell(oldRender.bind(this), ()=>this.forceUpdate()); return this._reaction.get(); } } class Timer { @observable count; constructor(text) { this.count = 0; } } const AppState = new Timer(); @observer class App extends React.Component { onClick=()=>{ this.props.timer.count++ } render(){ console.log('render'); const {timer} = this.props; return ( <div> <div>{timer.count}</div> <button onClick={this.onClick}>click</button> </div> ) } } render(<App timer={AppState}/>, document.getElementById('root')); 

この例では、1つの欠点があります。コンポーネントの依存関係が変更される可能性がある場合はどうでしょうか。 次のコンポーネントをご覧ください

 class User extends React.Component { render(){ const {user} = this.props; return <div>{user.showFirstName ? user.firstName : user.lastName}</div> } } 

コンポーネントはuser.showFirstNameプロパティに依存し、さらに値に応じて、 user.firstNameまたはuser.lastNameいずれかに依存できます。つまり、 user.showFirstName == true場合、 user.showFirstName == true変更に反応するべきではありません。 user.showFirstName falseに変更されたため、プロパティuser.firstName場合、反応（およびコンポーネントレンダラーを実行）しないでuser.firstName 。

この点は、依存関係リストthis.dependencies = new Set()をセルクラスに追加し、 run()関数の小さなロジックを追加することで簡単に解決できます。そのため、反応のrender（）を呼び出した後、以前の依存関係のリストを新しいものと比較し、無関係な依存関係からサブスクライブを解除します。

 class Cell { constructor(){ ... this.dependencies = new Set(); } get() { if (CurrentObserver) { this.reactions.add(CurrentObserver); CurrentObserver.dependencies.add(this); } return this.value; } } class ComputedCell { track(){ const prevObserver = CurrentObserver; CurrentObserver = this; const oldDependencies = this.dependencies; //    this.dependencies = new Set(); //          const newValue = this.computedFn(); //        for(const dependency of oldDependencies){ if(!this.dependencies.has(dependency)){ dependency.unsubscribe(this); } } CurrentObserver = prevObserver; return newValue; } } 

2番目のポイントは、オブジェクトの多くのプロパティをすぐに変更した場合ですか？ 依存コンポーネントは同期的に更新されるため、2つの追加コンポーネント更新が取得されます

 comment.text = 'edited text'; //    comment.editedCount+=1; //    

不要な更新を避けるために、この関数の先頭でグローバルフラグを設定できます。 @observerデコレーターはすぐにthis.forceUpdate()呼び出さず、このフラグを削除したときにのみ呼び出します。 そして簡単にするために、このロジックをactionデコレータに配置し、フラグの代わりにデコレータを他のデコレータ内で呼び出すことができるため、カウンタを増減します。

 updatedComment = action(()=>{ comment.text = 'edited text'; comment.editedCount+=1; }) let TransactionCount = 0; let PendingComponents = new Set(); function observer(Component) { const oldRender = Component.prototype.render; Component.prototype.render = function(){ if (!this._reaction) this._reaction = new ComputedCell(oldRender.bind(this), ()=>{ TransactionCount ?PendingComponents.add(this) : this.forceUpdate() }); return this._reaction.get(); } } function action(fn){ TransactionCount++ const result = fn(); TransactionCount-- if(TransactionCount == 0){ for(const component of PendingComponents){ component.forceUpdate(); } } return result; } 

その結果、非常に古い「オブザーバー」パターンを使用するこのアプローチ（オブザーバブルRxJSと混同しないでください）は、イミュニティアプローチよりもポイント更新コンポーネントのタスクにより適しています。

欠点のうち、リテラルではなくクラスを介してオブジェクトを作成する必要があることに気付くことができます。つまり、サーバーから一部のデータを@observableてコンポーネントに渡すことはできません。クラスオブジェクトを@observableデコレータでラップして追加のデータ処理を実行する必要があります。

おわりに

— — "" mobx. mobx @computed ( ) mobx- react-.