前回の記事では、計算属性の実装の原則を少し紹介しました。
レンダリングウォッチャーとユーザーウォッチャーです。
実際、一度計算されたプロパティを理解すれば、この2つのウォッチャーを実行する残りのプロセスは簡単に理解できます。
レンダー/レンダーウォッチャー
mountComponentメソッドにそのような段落があります：
ウォッチャーのコンストラクタには、依存関係の収集を実行するためにコンストラクタの費用で get メソッドが呼び出されることを示す行があります。つまり、コンポーネントのデータは最初にウォッチャーにバインドされます。
watcher.get
getメソッドは、基本的にレンダリングウォッチャーのvm._updateメソッドを実行し、最初の依存関係の収集は呼び出し中に実行されます。
焦点はpushTargetメソッドとpopTargetメソッドです。これは依存関係の収集にとって重要です。
targetStack
Dep.targetは、現時点でのwatcher.getメソッドの呼び出し元であるグローバル・オブジェクトで、コンポーネント・レンダリング処理ではウォッチャーをレンダリングしています。
targetStackの件は注目に値します。これは、レンダリング関数が純粋に親コンポーネントと子コンポーネントの入れ子関係になっているためです。つまり、親コンポーネントのレンダリングの途中で、自己完結型のレンダリングに移行し、この時点でグローバルウォッチャーを置き換えないと、依存関係の収集がエラーになるため、スタック構造を使用してウォッチャーのレンダリングを保存するようにバインドされています。
レンダリングウォッチャーの概要
依存関係の収集はウォッチャーが最初にレンダリングされたときに行われるので、データが更新されたときや属性が計算されたときに、updateメソッドがトリガーされてビューが更新されます。全体のプロセスは、継続的な依存関係の収集と更新のディスパッチです。
もう1つの注目点は、targetStackスタック構造が、コンポーネント単位で更新する際の依存関係収集エラーに対処するために存在することです。
users watcher
コンポーネントを初期化する際、ウォッチ・オブジェクトに対して次のような処理が行われ、実際には各キーに対してウォッチャー・インスタンスが作成されます。繰り返しますが、ほとんどの場合、この作成処理には依存関係のコレクションが伴います。
注意: ここでは vm.$watcher メソッドを使用しています。
vm.$watch
即座に。
上記の関数でcreateWatcherに渡されるキーは、文字列か式でなければなりません。expOrFnに渡される文字列の場合、パスはオブジェクトの値を直接取得するために解析されます。
createWatcherに渡されたhandler関数はwatcherコンストラクタに渡されたcbなので、runメソッドではこのcb(handler)関数が実行され、更新前後の値が取得されます。
options
ユーザー・ウォッチャーには、ウォッチャーを設定するためのオプションがあります。
1. deepは、リスニング・オブジェクトの値を再帰的に取得し、リスニング処理中に依存関係の収集を実行します。
2. lazy は、プロパティの計算に使用される遅延値です。
3. sync は、wathcer の run メソッドが同期的に呼び出されるかどうかを示します。
4. before 非同期キューのウォッチャーを更新する前に呼び出されるメソッド。
5. ユーザータグがユーザーウォッチャーかどうか
6. immediatly vm.$watchメソッドでimmediatlyがtrueの場合、cb/ハンドラ関数は非同期ではなく、即座に呼び出されます。
users watcher
expOrFnがvm._update、beforeがbeforUpdateフック関数の場合はレンダリングウォッチャーとなり、expOrFnが関数でlazyプロパティがtrueの場合はコンピューテッドプロパティとなります。
