@@ -4,15 +4,15 @@ route トランジションのパイプラインをよく理解するために
44
55![ ] ( 01.png )
66
7- そして、私達のレンダリングされたコンポーネントツリーを新しいものに更新することを必要とする新しいパス ` /a/d/e ` にナビゲートします:
7+ そして、私達のレンダリングされたコンポーネントツリーを新しいものに更新するのを必要とする新しいパス ` /a/d/e ` にナビゲートします:
88
99![ ] ( 02.png )
1010
11- どうやって私達はそれについて行けるでしょうか?私達はここでする必要があるいくつかの事があります :
11+ どうやって私達はそれについて行けるでしょうか?私達はここでいくつかの事をする必要があります :
1212
13131 . 潜在的にコンポーネント A を再利用することができます。なぜなら、トランジション後のコンポーネントツリーは同じであるためです。
1414
15- 2 . 非活性化化し 、そしてコンポーネント B と C を削除する必要があります。
15+ 2 . 非活性化し 、そしてコンポーネント B と C を削除する必要があります。
1616
17173 . 作成し、コンポーネント D と E を活性化する必要があります。
1818
@@ -32,21 +32,21 @@ vue-router で、任意のトランジションフックで実装することに
3232
33332 . ** 検証フェーズ (Validation phase):**
3434
35- 全て現状のコンポーネントが非活性化できるかどうかチェックし、全ての新しいコンポーネントが活性化できます 。これは、` canDeactivate ` と ` canActivate ` の route 設定のフックを呼び出しとチェックで可能です。
35+ 全て現状のコンポーネントが非活性化できるかどうかチェックし、全ての新しいコンポーネントを活性化できます 。これは、` canDeactivate ` と ` canActivate ` の route 設定のフックを呼び出しとチェックで可能です。
3636
3737 ![ 検証フェーズ(validation phase)] ( 04.png )
3838
39- ` canActivate ` チェックはトップダウンですが、` canDeactivate ` チェックはボトムアップなバブルであることに注意してください 。
39+ ` canActivate ` チェックはトップダウンですが、` canDeactivate ` チェックはバブルのようなボトムアップであることに注意してください 。
4040
41- これらの全てのフックが潜在的にトランジションを中止することができます。もしトランジションが検証フェーズの間で中止される場合は 、ルーターは現状のアプリケーション状態を保存し、前のパスを復元します。
41+ これらの全てのフックが潜在的にトランジションを中止することができます。トランジションが検証フェーズの間で中止される場合は 、ルーターは現状のアプリケーション状態を保存し、前のパスを復元します。
4242
43433 . ** 活性化フェーズ (Activation phase):**
4444
4545 一度全ての検証フックが呼び出され、それらのトランジションの中止がない場合、トランジションは現在有効であると言われます。ルーターは現状のコンポーネントを非活性化し、新しいコンポーネントを活性化します。
4646
4747 ![ 活性化フェーズ(activation phase)] ( 05.png )
4848
49- これらのフックは検証フックの同じ順序で呼び出されますが、これらの目的は、目に見えるコンポーネントの切り替えが実行される前に、クリーンアップ/準備 作業をするための機会を与えるためです 。インターフェイスは影響を受けるコンポーネントの ` deactivate ` フックと ` activate ` フックの全てが解決されるまで更新されません。
49+ これらのフックは検証フックの同じ順序で呼び出されますが、これらの目的は、目に見えるコンポーネントの切り替えが実行される前に、クリーンアップ/準備作業をするための機会を与えるためです 。インターフェイスは影響を受けるコンポーネントの ` deactivate ` フックと ` activate ` フックの全てが解決されるまで更新されません。
5050
5151 ` data ` フックは ` activate ` フックが解決された直後に呼び出され、コンポーネントが再利用されるときも呼び出されます。
5252
0 commit comments