All language subtitles for 12. Understanding Event Driven Code Execution

Já alcançamos muito nesta seção.

E notei que todo esse código parece meio intimidador e não se preocupe, isso se tornará muito mais fácil, mas

acho super importante aprendê-lo da maneira mais difícil primeiro, para que você nunca esqueça o que

está acontecendo nos bastidores.

Agora, uma coisa crucial com a qual observo que as pessoas frequentemente enfrentam dificuldades é que a ordem de execução do

seu código aqui não é necessariamente a ordem na qual você o escreve.

Por exemplo, este ano será realmente executado após esse código e será executado depois que já tivermos

enviado a resposta.

Isso tem duas implicações importantes para quem enviar a resposta não significa que nossos ouvintes de eventos estejam aqui com

nossa dívida.

Eles ainda serão executados mesmo se a resposta já tiver desaparecido.

Mas também significa que, se fizermos algo no ouvinte de eventos que deve influenciar a resposta, é uma

maneira errada de configurá-la.

Também devemos mover o código de resposta para o ouvinte de eventos.

Se tivéssemos essa dependência.

Mas isso também significa que é super importante entender que solicitamos ou codificamos como o servidor de criação

HTP.

Estes são alguns exemplos em que nenhuma perseguição usa um padrão no qual você passa uma função para uma função e

o nó executará as funções passadas pelo DS em um momento posterior chamado de forma assíncrona.

Agora, nem sempre é o caso de uma função transmitida ser

necessariamente executada posteriormente, mas nenhum J usou esse padrão intensamente e, claro, permite saber

quando isso ocorre e quando o nó executa algo de forma assíncrona. casos.

Nenhuma chance não executará imediatamente essa função.

Em vez disso, o que ele faz quando encontra essa linha pela primeira vez é que ele simplesmente adicionará um

novo ouvinte sem eventos internamente, gerencia todos esses ouvintes internamente.

Nesse caso, para o evento final da solicitação, que será acionado automaticamente assim que nenhuma alteração for

feita.

A análise da solicitação também faz algo que nenhuma perseguição faz por você.

E então chamará essa função para você.

Uma vez feito isso, no final, você pode pensar nisso como se não houvesse um registro interno de eventos

e ouvintes para esses eventos e uma função como essa é um ouvinte e, quando

servido, algo acontece, então, quando não há chance de analisar sua solicitação vai passar pelo registro e ver.

Concluí a solicitação e agora devo enviar os eventos finais.

Vamos ver quais ouvintes eu tenho para isso e, então, encontraremos essa função e quaisquer outras funções que você

possa ter registrado para isso e agora as chamarão, mas ela não postará a execução média do código e isso

é tão importante para entender.

Então, por exemplo, aqui agora, desde que mudei a resposta de retorno e, para essa função, o fluxo é assim.

Agora será atingido como se fosse uma declaração e, se essas condições forem atendidas, ele entrará dentro dela.

Ele registrará o DS nos manipuladores e não executará imediatamente essas duas funções.

Em vez disso, as funções são apenas registradas internamente no registro do emissor de eventos e, em

seguida, elas passam para a próxima linha e, portanto, agora, se eu reiniciar o servidor e salvar no código e

reiniciar o servidor aqui.

Você verá que, se eu inserir algo aqui, na verdade, sou redirecionado para esta página ou nem mesmo o redireciono, como você

pode ver.

Não existe um código de status 300 em vez de apenas esta página do Lote, porque ele executa essas linhas porque, como

agora mencionei várias vezes, ele não será executado imediatamente.

E essa declaração de retorno, portanto, não encerrará essa função abrangente aqui.

Em vez disso, apenas registra esse retorno de chamada e passa imediatamente para as próximas linhas.

E acabaria por executar essa linha, mas isso já é tarde demais.

É também por isso que obtemos o erro do hetero não pode definir aqui, porque ele já moveu o longo e

executou esse código.

De repente, a análise da solicitação terminou e ele executou esse código e tentou enviar novamente

uma resposta que obviamente é tarde demais, porque já havia feito aqui.

Agora eu sei que isso é difícil de entender, mas é um conceito crucial que você possa registrar funções

de código que serão executadas em algum momento no futuro, mas não necessariamente no momento.

E, portanto, a próxima linha de código que esse código aqui pode executar ou será executada antes desse código, simplesmente porque é apenas

um retorno de chamada a ser chamado em algum momento no futuro.

E essa configuração é importante porque, caso contrário, o nó terá que pausar até que seja concluído, pausar até que

ele tenha gravado o arquivo e, se o fizer, simplesmente reduzirá a velocidade do servidor e não poderá lidar com

nossas solicitações recebidas ou fazer qualquer coisa desse tipo até está feito.

E não é isso que queremos.

Não queremos bloquear nossa execução de código.

Nós sempre queremos estar nessa espera por novos eventos, repetir o loop de eventos e, em seguida, executar o código apenas

uma vez que deve ser executado e nunca bloquear esse loop de eventos por muito tempo.

E é por isso que temos essa configuração e isso tem uma implicação para esta linha e para essa linha de aplicativo

para design é que chegamos cedo demais.

Então, para um branco, deveríamos voltar aqui.

Simplesmente retornamos a solicitação para que isso seja executado.

Mas a linha depois disso não.

E a aplicação importante sobre essa linha será discutida na próxima palestra.