2015-01-04 3 views
6

CasperJS가 호출 스택과 관련하여 이벤트를 처리하는 방법에 대해 궁금합니다. CasperJs()는 이전 함수에서 발생한 이벤트를 기다리고 있습니까?

은의 우리가 몇 가지 코드가 있다고 가정하자 : pendingWait, loadInProgress 및 navigationRequested :

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(); 

을 그때() 3 flags에 대해 확인을 기다리는 것을 알고있다. 호출 스택을 출력하면 exit() 함수에 emit 호출이 표시되므로 이벤트가 끝날 때까지 start()가 완료된 것으로 간주되지 않습니까? 나는. 이벤트가

를 완료 할 때까지 다음() 대기 나는 60 초 대기 이것을 테스트, 그리고 출력 얻었다 : 특정 시간 제한을 초과하면 트리거 것인지 확실하지 않았다 비록

start 
foo 
done 

을 그 다음에().

답변

3

비동기 적으로 실행되는 함수는 염두에 두어야합니다. 귀하의 경우, 출력물의 처음 두 줄은 페이지가로드되고 즉시 done이 인쇄 된 후 60 초 후에 인쇄됩니다.

  • 모든 then*wait* 기능은 큐에 단계를 삽입하지만, 그 자체가 비동기 :

    것 알고 있습니다.

  • casper.emit은 등록 된 이벤트 처리기를 찾아 즉시 (비동기가 아닌) 실행합니다.
  • casper.echo은 즉시 인쇄합니다 (비동기는 아닙니다).

이벤트 순서는 자체가 단계 기능 인 start 콜백에서 이벤트가 트리거되고 즉시 실행된다는 것입니다. 이 실행 된 이벤트에는 wait 호출이 포함되어 현재 호출 후 지연 단계가 추가됩니다 (우리는 여전히 start 콜백에 있음). 그런 다음 echo이 실행되고 현재 단계가 완료됩니다. 다음 단계는 60 초를 기다리는 것으로 시작됩니다. wait에 콜백이 전달되지 않았으므로 다음 예약 된 단계가 실행됩니다. 이것은 echo('done')을 포함하는 마지막 단계입니다.

따라서 엄격 이전 단계의 이벤트 실행 기다리지 않는다 then 말하고 있지만,이 경우 (통상 setTimeout 통해 수행) 제어 흐름 중 더 체류 없었다 및 CasperJS 단계 프로세서 적발 내측 wait 단계.

+0

매우 철저히 답변 해 주셔서 감사합니다. wait 문을 시간이 좀 걸리는 비동기 논리로 바꾼 경우에도 동일한 출력을 기대해야합니까? 내 이해에서 시작 콜백은 마지막 비동기 (non-asynch) 문장이 끝나면 끝난다. (심지어 그 문장이 어떤 사건에 있어도) 그 지점보다 먼저 실행되지 않을 것이다. –

+1

당신의 관찰 결과는 정확하고 출력은 같지만 타이밍은 달라질 것입니다. 왜냐하면 지금 블로킹 대기가'this.echo ('foo'); –