Czy CasperJs następnie() czeka na emitowane zdarzenia w poprzedniej funkcji?

Question

Jestem po prostu ciekawa, jak CasperJS obsługuje zdarzenia związane ze stosem wywołań.

powiedzmy mamy pewne kod:

casper.on('foo', function() { 
    this.wait(60000); 
    this.echo('foo'); 
}); 


casper.start('http://www.stackoverflow.com', function() { 
    this.echo('start'); 
    this.emit('foo'); 
}); 


casper.then(function() { 
    this.echo('done'); 
}); 

casper.run(); 

wiem, że wtedy() będzie czekać sprawdzić przed 3 flags: pendingWait, loadInProgress i navigationRequested. Wydrukowanie stosu wywołań pokazuje wywołanie emitujące, które ma być funkcją start(), więc start() nie zostanie uznany za zakończony, dopóki zdarzenie się nie zakończy? To znaczy. następnie() czekać, aż zdarzenie zakończy

testowałem to z czekać 60 sekund, a ja dostawałem wyjście:

start 
foo 
done 

Choć nie byłem pewien, czy przekroczenie określonego czasu by wyzwolić Potem().

Answer 1

Należy pamiętać, które funkcje są wykonywane asynchronicznie. W twoim przypadku pierwsze dwa wiersze wydruku są drukowane natychmiast po załadowaniu strony i wydrukowaniu done 60 sekund później.

Co trzeba wiedzieć:

• Wszystko then* i wait* funkcje wstawi krok w kolejce, ale sami są asynchroniczne.
• casper.emit wyszuka zarejestrowany moduł obsługi zdarzeń i wykona go natychmiast (nie asynchronicznie).
• casper.echo wydrukuje coś natychmiast (nie asynchronicznie).

Kolejność zdarzeń polega na tym, że w wywołaniu zwrotnym start, które samo w sobie jest funkcją krokową, zdarzenie jest wyzwalane i natychmiast wykonywane. To wykonane zdarzenie zawiera wywołanie wait, które dodaje opóźniony krok po bieżącym (nadal jesteśmy w wywołaniu zwrotnym start). Następnie zostanie wykonane echo i bieżący krok zostanie zakończony. Następny krok zaczyna się od odczekania 60 sekund. Ponieważ nie przekazano żadnego wywołania zwrotnego do wait, wykonywany jest następny zaplanowany krok. To jest ostatni krok, który zawiera echo('done').

Tak ściśle mówiąc then nie czekać na realizację zdarzeń z poprzedniego etapu, ale w tym przypadku nie było wyrwać przepływu sterowania (zwykle odbywa się poprzez setTimeout) i procesor krok CasperJS schwytał wewnętrzna wait krok.