Vue Asynchronous Event Update & Asynchronous DOM Update Solution __vue

Vue Asynchronous Event Update & Asynchronous DOM Update Solution

Vue Asynchronous Dom Update solution question Action 1 correct posture 21 trials 3 and confused.

1. Question

Recently encountered a somewhat awkward demand.

Entering a subpage requires four interfaces to get four copies of the data "A,b,c,d".
One of the a,b happened to father, in the parent page with V-IF instructions to ensure A and B exist, and then to show the child page.

Now, C and D must be in the sub page to get it. C relies on the browser's query pid,d to rely on a field of C C.pgid.

Drawing a picture, presumably this is the demand:

And then my old idea of realization was this:

Using Typescript

  Private created () {
  //request C immediately after request D
   THIS.FETCHC (). then (this.fetchd);

  Background request C
  private FETCHC () {this
   . $store. Dispatch (' resource/c ', this.pid);

  Obtain C private Get
  C () {return this
    . $store. getters[' resource/c '] (this.pid)

  from the store Private Get PID (): Number {return number
    (this. $route. query.pid);
  }

  Private Get Pgid () {
    if (!THIS.C) {return
      null;
    }

    return this.c.pgid;
  }

Background request D
  private fetchd () {
    if (!this.pgid) {return
      ;
    }

    return this. $store. Dispatch (' resource/d ', this.pgid);
  }

 Store get D
  private got D () {return this
    . $store. getters[' resource/d '] (this.pgid);
  }

Dispacth C immediately after then dispatch D. At this time, get C () does not guarantee must have got to, this.pgid more not necessarily can obtain, dispatch D method will be an error.

At that time a bit of a circle, in fact, very simple one thing, as long as the guarantee this.pgid existence of time to go to dispatch D on it. 2. Action 2.1 correct posture

Change a little bit of code:

The using Typescript

  private created () {
  //request C does not immediately request D
   THIS.FETCHC ();  This row was changed
  }

  //Background request C
  private FETCHC () {this
   . $store. Dispatch (' resource/c ', this.pid);
  }

  Obtain C private Get
  C () {return this
    . $store. getters[' resource/c '] (this.pid)

  from the store Private Get PID (): Number {return number
    (this. $route. query.pid);
  }

  Private Get Pgid () {
    if (!THIS.C) {return
      null;
    }

    return this.c.pgid;
  }

Background request D, by listening to the value of the Pgid, before going to the Fetchd
  @Watch (' pgid ')    ///This row was changed
  private Fetchd () {
    if (!this.pgid) { return
      ;
    }

    return this. $store. Dispatch (' resource/d ', this.pgid);
  }

 Store get D
  private got D () {
    if (!this.pgid) {return;}  The trip was changed back to this
    . $store. getters[' resource/d '] (this.pgid);
  }

Running up, everything is perfect. Data for all two interfaces have been obtained.

This is a train of thought, put the center of gravity on the data has not got, with watch monitoring, and so on, and then to send a second request.

But a bit flustered, this piece of feeling is still a little bit fascinated.

If I don't put my thoughts on the data, I go to control the request (feel like this is more consistent with the development of the idea, the code is easier to understand), there is no life cycle of the moment, the first request back, get the first data has been successfully obtained, at this time of life cycle, the second request began.

The second request can be put in the $nexttick.
Regardless of the speed of the dispatch method, in the end get and dispatch who first executes. Is there a sequence of.

2.2 An experiment

Take settimeout as a dispatch test.

 
Run Result:


There is a picture of the truth, look at the picture learning:

The official explanation for $nexttick is:

Performs a deferred callback after the next DOM update loop ends. Use this method immediately after modifying the data to get the updated DOM.

The official interpretation of the created method is:

Called immediately after the instance creation is complete. In this step, the instance has completed the following configuration: Data observations (Observer), operations of properties and methods, Watch/event event callbacks. However, the Mount phase has not yet started, $el properties are not currently visible.

The official interpretation of the mounted method is:

The El is created by a new VM. The $el is replaced and the hook is called after it is mounted to the instance. If the root instance mounts a document element, when mounted is invoked the VM. $el is also in the document.

Note that mounted will not commit all subassemblies to be mounted together. If you want to wait until the entire view is rendered, you can use the VM. $nextTick Replace mounted:

Mounted:function () {this
  . $nextTick (function () {//Code, that'll run only after the
    //entire view has is En rendered
  })
}
 
Oh, that is, after the Vue created method is finished, the mounted method begins, followed by the $nexttick method.

Bah, I don't believe it.

I changed the delay to 0 and my request was huge.

Created:function () {
        //I change this to 0
        settimeout () => {
          this.pgid = m;
          Console.log (' Time Out ');
        }, 0;
        this. $nextTick (() => {
          Console.log (' next tick ');
          This.pgid = ten;
        })
        Console.log (' created ');
      }
 
Results:


Well, there's no change, or $nexttick fast.

Now, at least understand one thing: encounter asynchronous events, you use the idea of intercepting asynchronous events is not, mounted and nexttick can not stop, with settimeout delay you do not know the delay of the asynchronous event is specific to how many seconds. Actually, the asynchronous event executes more time later. And it's much later than the DOM creation and rollout time.

So two requests are issued before and after the created method, and the second request relies on the parameters of the first request, which is certainly incorrect. 2.3 and confused .

Get must be after the created method.

Not....


Get and Dispatch methods who first perform ... For example, this get D and fetch D are all dependent on Pgid,pgid, who changes first. Not necessarily ....

Use the data to control everything honestly.


Finish

 Reference: 
 https://juejin.im/post/5a6fdb846fb9a01cc0268618