Masterização do JavaScript Seção 1: conceitos críticos

1. JavaScript conceitos críticos Introdução: Bem-vindo a esta seção sobre conceitos críticos em JavaScript. Nesta seção, vamos lidar com o que eu acho que são conceitos críticos sobre a linguagem e como o JavaScript funciona. Agora, alguns de vocês podem querer avançar em duas seções que se concentram mais no aspecto da linguagem do JavaScript. Mas eu gostaria de exortar os pacientes, esses conceitos são fundamentais. Agora, ao começar nesta seção, alguns dos conceitos podem parecer básicos porque são. Mas mesmo que você esteja trabalhando com JavaScript há algum tempo, tenho certeza de que aprenderá alguma coisa. Então continue com isso. Agora, por que esses conceitos são essenciais? Por que é importante entender como a linguagem funciona? Porque uma parte fundamental da compreensão de qualquer bom desenvolvedor é saber por que você faz certas coisas. O y possibilita ajustar padrões ou códigos para atender às suas necessidades específicas. Eles podem facilitar o pensamento crítico. E esses conceitos fornecem o porquê de muitas coisas que fazemos em JavaScript, sobre as quais falaremos mais tarde. Na verdade, como parte das seções posteriores, talvez você queira voltar e revisitar alguns desses tópicos, como o ciclo de eventos ao lidar com código assíncrono. Portanto, é importante passar algum tempo falando sobre o mecanismo JavaScript, a pilha de chamadas, a pilha de memória. O fato de o JavaScript ter um único encadeamento, o ambiente de execução e o loop de eventos. Então, vamos direto ao assunto. 2. O ambiente JavaScript em tempo de execução: Para que possamos usar o JavaScript, precisamos de um ambiente onde ele seja executado. Agora, o JavaScript não requer muitas ferramentas para escrever código. Na verdade, podemos simplesmente abrir um editor de texto simples e começar a escrever JavaScript. Mas para que esse código faça sentido ou faça qualquer coisa, precisamos disponibilizar o código para um ambiente de execução de JavaScript. Agora, existem dois ambientes de execução principais que compõem a maior parte do uso do JavaScript, do navegador e do NodeJS. Assim, podemos executar o JavaScript e concluir alguma tarefa usando o navegador ou o node. Agora, esses dois não são os únicos ambientes que poderíamos usar, mas são os mais importantes e os mais predominantes. Agora, existem algumas semelhanças entre o node e os navegadores e, em seguida, existem algumas diferenças. Vamos falar sobre eles brevemente. Primeiro, tanto o navegador quanto o node são simplesmente um aplicativo. Em cada caso, eles precisam estar instalados no seu computador para usá-los. Instalamos o Node no início do curso. Quando eu inicio um navegador, neste caso o Chrome, estou iniciando esse aplicativo a partir do meu computador. Agora, o mesmo acontece com o node. Nós simplesmente o usamos de forma diferente. Precisamos usá-lo no terminal ou no prompt de comando. E geralmente não usamos uma interface GUI. Por exemplo, eu posso acessar o node digitando isso. E agora eu tenho um prompt de nó. É assim que eu uso o node. Outra semelhança é que esses aplicativos, ou seja, tanto o navegador quanto o node, são escritos com a mesma linguagem de computador. Agora, no caso do Chrome e da maioria dos navegadores, o núcleo desse aplicativo está escrito em C plus plus. A GUI geralmente é uma linguagem diferente, mas o núcleo é C plus plus. Agora, o núcleo do NodeJS também está escrito em C plus plus com algum código JavaScript que atua como um invólucro para alguns dos comandos que usamos. O código. Esses dois aplicativos são escritos no navegador e o node é muito semelhante, mas não é isso que possibilita o uso do JavaScript em cada um desses ambientes. Para que um ambiente de execução de JavaScript permita o uso do JavaScript, ele precisa de algo para interpretar a linguagem, ler o JavaScript e traduzi-lo para o computador. Essa peça muito importante é chamada de mecanismo JavaScript. Tanto o navegador quanto o node exigem um mecanismo JavaScript para usar o JavaScript. Agora, o mecanismo JavaScript é apenas uma parte de todo o aplicativo. Há muitas outras peças um navegador e muitas outras partes no node. Vamos dar uma olhada em um diagrama que ilustra o ambiente de execução do nosso navegador. Essas são todas as peças sobre as quais falaremos porque interagimos com elas quando usamos JavaScript no navegador. Então, se tudo isso representa o navegador e o que ele contém, podemos ver que há coisas que não fazem parte do mecanismo JavaScript, que está representado aqui. Às vezes, fazemos coisas em JavaScript que usam partes do aplicativo do navegador que não fazem parte do mecanismo JavaScript. Agora, essas outras partes ou peças são algumas das coisas que são diferentes entre um navegador e um conhecido. Por exemplo, em um navegador, interagimos com o DOM, amplamente representado aqui nas APIs da web. Bem, isso não é algo que fazemos no Node. Não há DOM que faça parte do node. No entanto, o conhecido torna possível realizar outros tipos de tarefas. Tarefas que são necessárias em um servidor, como gravar um arquivo em um disco rígido ou iniciar um servidor. Essas são coisas que não podemos fazer em um navegador. Portanto, existem algumas diferenças. Vamos dar uma olhada em outra diferença bem rápido. Então, aqui em um navegador, se eu abrir o console, posso exibir a janela. Isso exibe o objeto da janela. Esse é o ambiente global em que estamos escrevendo código. Quando estamos escrevendo, o JavaScript está dentro da janela. E há muitas coisas associadas à janela, das quais podemos usar. Agora, o nó não tem uma janela. Se digitarmos janela aqui, referência não capturada, nossa janela não será definida. No entanto, podemos digitar global. E obtemos informações sobre o mundo todo. E isso seria o equivalente ao Window no lado do navegador. Agora, é claro, haverá semelhanças. Por exemplo, você pode ver setTimeout aqui em global. Settimeout também está disponível no navegador. Você pode ver que não está no mecanismo de JavaScript. Na verdade, faz parte da API da web. A mesma coisa com o node. Não faz parte do mecanismo de JavaScript, mas temos acesso a ele. E podemos fazer algo como console.log aqui. E assim como podemos fazer em um navegador. Agora, nos próximos tópicos, falaremos sobre essas diferentes partes de um navegador, pois elas são essenciais para entendê-las. Para escrever com eficácia, JavaScript. Node também tem partes adicionais, mas vamos nos concentrar principalmente no navegador. Primeiramente, falaremos sobre o mecanismo JavaScript. 3. Como entender o mecanismo JavaScript: Simplificando, o mecanismo JavaScript é um programa que executa código JavaScript. Então, olhando nosso diagrama, se tivermos algum código JavaScript, o mecanismo JavaScript está no comando. É a única peça que sabe o que fazer com o código. Isso o traduz em algo que o computador pode entender. Agora, os mecanismos iniciais de JavaScript no início eram intérpretes, que significa que eles processavam o código JavaScript linha por linha, convertendo-o em bytecode para que pudesse ser executado. Os intérpretes são encerrados para começar a executar o código, algo que era necessário no ambiente do navegador. Mas eles podem ser mais lentos em geral quando comparados à compilação do código. O código compilado está convertendo o programa em código de máquina para que ele seja executado de forma otimizada. Os mecanismos JavaScript mais recentes são muito mais otimizados. Eles usam uma combinação de intérprete e compilador JIT, compilação ou compilador JIT para otimizar o código. Isso traz o melhor dos dois mundos. compilação do Jit usa o frio que pode ser otimizado e o compila. Por exemplo, se um trecho de código é executado muito, ele pode ser compilado em código de máquina. E então, quando esse trecho de código é executado, ele é otimizado e, portanto, mais rápido. Agora, existem vários mecanismos de JavaScript. O que provavelmente é o mais conhecido é o motor V8. Esse é o mecanismo usado no navegador Chrome e também no node. Esse mecanismo foi escrito pelo Google para o Chrome usando o C plus plus. E é de código aberto. É provavelmente o mecanismo mais conhecido porque, quando foi construído, melhorou a velocidade dos mecanismos JavaScript existentes. O Google estava usando o JavaScript para fazer algumas coisas incríveis naquela época. Pense nos diferentes aplicativos do Google escritos com JavaScript. De qualquer forma, eles queriam que fosse mais eficiente. Então, eles escreveram o motor V8 para fazer exatamente isso. Outros mecanismos de JavaScript também seguiram o exemplo para tornar seus mecanismos mais eficientes. Essa melhoria no desempenho é importante para estar ciente dessa ideia de usar um compilador JIT com um intérprete para ajudar a otimizar o código. A razão pela qual isso é importante porque falamos sobre escrever código de certas maneiras aumentar o desempenho ou evitar coisas em nosso código que poderiam diminuí-lo. Muitas vezes, isso tem a ver com a forma como o mecanismo JavaScript manipula o código e é capaz de otimizá-lo. Agora, aqui estão alguns outros mecanismos de JavaScript que você pode ter encontrado. Já mencionamos o V8 que era de código aberto, desenvolvido pelo Google. É usado no Chrome e no NodeJS. Macaco-aranha. Esse foi o primeiro mecanismo de JavaScript e hoje é usado no Firefox. E, aliás, o primeiro mecanismo de JavaScript foi escrito por Brendan Eich quando ele inventou o JavaScript e, como diz a história, fez em dez dias. Agora, o núcleo do JavaScript, que também é código aberto e foi desenvolvido pela Apple para o Safari. Então esse é o motor que o Safari usa. Outro que provavelmente devemos mencionar é o chakra. E isso é usado no Microsoft Edge. Então, o mecanismo JavaScript da Microsoft. Agora, com todos esses mecanismos de JavaScript diferentes em navegadores diferentes, como sabemos se o código JavaScript que escrevemos funcionará da mesma forma em cada navegador. No início da história do JavaScript, esse era um problema real. Havia diferenças. Naqueles dias. Passamos muito tempo nos preocupando com as diferenças nos navegadores. Bibliotecas como o jQuery ajudam a resolver esse problema e se tornaram muito populares por causa disso. Agora, por causa dessas diferenças, era necessário haver um padrão e é aí que entra o script da Acme. Esse é um padrão que o JavaScript segue. Um script AGMA é uma especificação que todos os mecanismos de JavaScript agora seguem. Isso permite várias implementações independentes, mas garante que nosso código funcione da mesma forma. Portanto, quando mudanças são feitas no script padrão, os índios devem ser atualizados para suportar essas mudanças. Algumas atualizações são mais rápidas do que outras. E é por isso que temos sites como esse. Posso usar.com que nos diz quais navegadores suportam determinadas implementações? Assim, podemos ver o histórico de diferentes navegadores e quando eles começaram a oferecer suporte aos módulos ES neste exemplo. Agora, é também por isso que usamos o transpiler. Um transpiler, como o babble, permite que você escreva código usando o padrão de scripts Ekman mais leve, mas depois gera o código JavaScript para um padrão mais antigo. Portanto, uma forma anterior de JavaScript que os mecanismos de navegador mais antigos podem executar. Isso também pode ser chamado de compilador porque tecnicamente, você está compilando código em outro formato e em uma versão mais antiga do JavaScript. Tudo bem, então isso é suficiente sobre os mecanismos de JavaScript. Agora precisamos entrar mais nos detalhes e falar sobre a pilha e a pilha de chamadas nos mecanismos. Essas duas coisas são usadas com frequência ao codificar em JavaScript, mesmo que você não saiba disso. 4. O salto da memória e a pilha: Agora vamos nos aprofundar em dois recursos do mecanismo JavaScript que são importantes de entender: a memória e a pilha de chamadas. Eles são usados durante a execução do código. Primeiro, descreverei cada um deles e depois os veremos em ação para entender melhor como eles estão envolvidos na execução do código. Agora, a pilha de memória, como o nome indica, tem a ver com a alocação de memória. Sempre que você define uma função de objeto variável, qualquer coisa parecida com essa em seu código, precisa haver um local para armazená-la. Então, essas variáveis aqui seriam armazenadas na pilha de memória. Sempre que uma declaração é encontrada, como essa, o valor é colocado na pilha de memória e, em seguida, a localização desse valor é colocada na variável. Então, sempre que o código precisa desse valor, da função ou do que quer que esteja armazenado, ele usa o local da memória para procurá-lo. Agora, a memória tem uma quantidade limitada de memória, então programas complexos que têm muitas variáveis e objetos aninhados podem consumir essa memória. O mecanismo JavaScript tenta disponibilizar mais memória apagando os dados do programa que ele determina que não são mais necessários. Esse processo é chamado de coleta de lixo. Há coisas que você pode fazer como programador para auxiliar na coleta de lixo. E há coisas que você pode fazer que podem atrapalhar isso. Examinaremos isso com mais detalhes no tópico sobre coleta de lixo. Mas, por enquanto, vamos falar sobre a pilha de chamadas. Sempre que executamos o código, a pilha de chamadas é usada. É simplesmente um local na memória que acompanha a execução da função e as funções que serão executadas depois disso. Portanto, a ordem na qual esses comandos são executados. Agora, cada função é colocada em cima da função anterior. Portanto, a primeira função em está na parte inferior da pilha de chamadas. E então, como outras funções são chamadas, elas são colocadas em cima dela. Portanto, a pilha de chamadas segue uma abordagem de primeiro a entrar, último a sair. Agora, assim que a função ou comando for concluído, ele será removido da pilha de chamadas. Agora, como você pode ver no diagrama, há apenas uma única pilha de chamadas representada. O mecanismo JavaScript tem apenas uma pilha de chamadas para lidar com os comandos que estão sendo executados. Isso ocorre porque o JavaScript tem um único encadeamento, um termo do qual você já deve ter ouvido falar. Agora, um único thread significa que o mecanismo JavaScript só pode executar uma parte do programa por vez. Portanto, a pilha de chamadas lida com um comando por vez. E, como resultado disso, o JavaScript é síncrono. Os comandos só podem ser executados um por vez. Você provavelmente pode ver um possível problema com isso. E se invocarmos uma função que requer muito tempo para ser executada? Como podemos evitar que isso bloqueie outros códigos? Por exemplo, queremos que um usuário possa clicar em um botão e não precise esperar dois segundos para que o JavaScript termine antes de responder a esse botão. Agora, vamos nos aprofundar em como isso é tratado e como o mecanismo JavaScript lida com isso quando falamos sobre o ciclo de eventos. E também é por isso que é importante entender os padrões de JavaScript assíncronos em JavaScript. E essa é uma das partes críticas com as quais lidamos neste curso. Agora, em nosso diagrama, como você pode ver, temos um código muito simples. Vamos analisar isso com a pilha de memória e a pilha de chamadas para ilustrar como elas são usadas na movimentação do código. Basicamente, o que estamos fazendo é declarar duas variáveis, a e B. Então, temos uma função declarada. E então invocamos essa função aqui. Dentro da função, chamamos log do console. Chamamos setTimeout e passamos uma função para setTimeout. O tempo para isso é de 0 milissegundos. E então chamamos o log do console novamente. Então, vamos superar isso. Primeiro, temos as declarações de variáveis. E assim, cada um deles será colocado na pilha de memória. Há 1 segundo. Agora, não há uma ordem específica na forma como eles são colocados na pilha. Eles só precisam de uma referência de onde esse valor está localizado. Então temos nossa função. E isso também precisará ser colocado na pilha. E aí nós adicionamos isso à pilha de memória. Agora, se houvesse alguma variável declarada dentro dessa função, ela precisaria ser colocada lá. Ou se houver funções declaradas dentro dela, se houver outras coisas dentro que precisem entrar na pilha de memória, isso precisaria acontecer. Mas agora nos encontramos. A chamada para helloworld para essa função. Estamos invocando isso. Assim, o mecanismo JavaScript pega esse código de seu local de memória e, em seguida, pode começar a executá-lo usando a pilha de chamadas. Portanto, a função hello-world é colocada na pilha de chamadas que indica onde estamos na execução do código. Então, agora estamos dentro da função helloworld. Chegamos ao primeiro comando, que é uma chamada para console.log. Então, nós invocamos o registro de pontos do console e isso é colocado na pilha de chamadas. Agora podemos concluir esse comando. Assim, quando esse comando estiver concluído, ele será removido da pilha de chamadas e poderemos continuar. E podemos definir o tempo e setTimeout é adicionado à pilha de chamadas. No entanto, setTimeout é algo que faz parte da API da web, como você pode ver aqui. Então, o JavaScript não precisa fazer nada com isso. Então, basicamente, ele se livra disso. Ele o envia para o navegador e diz: Aqui, eu tenho que chamar o setTimeout. Aqui estão as informações. Vá em frente e cuide disso. E então, para que o mecanismo JavaScript se esqueça disso nesse momento, a API da web, configuraremos um cronômetro para esse setTimeout e ele lidará com tudo o que precisa ser tratado com setTimeout. Mas, neste momento, o mecanismo JavaScript simplesmente se esqueceu disso. Não está mais preocupado com isso. Ele simplesmente continua até o próximo comando, que é outro colega, console.log. E isso é adicionado à nossa pilha de chamadas. Somos capazes de cuidar disso imediatamente. Enviamos uma mensagem para o console, que por acaso é o mundo. E então isso é removido da pilha de chamadas. E então, nesse ponto, estamos no final da função hello-world. E isso é removido da pilha de chamadas. Agora, você pode ver como a pilha de chamadas pode ser construída com várias coisas. Se tivéssemos funções chamadas dentro de outras funções. E quanto mais funções aninhadas assim, mais coisas serão adicionadas à pilha de chamadas. E vamos nos basear nessa pilha de chamadas. Porque até que uma função retorne, até que seja concluída, ela não pode ser removida da pilha de chamadas. Agora, com toda essa ilustração, deixei o SetTimeout lá e disse que o mecanismo de JavaScript simplesmente se esqueceu disso. Bem, falaremos sobre isso quando chegarmos ao tópico sobre o loop de eventos, porque na verdade é o loop de eventos e a fila de mensagens que lidam com isso, que lidam com esses itens da API da web. Então, discutiremos isso em outro tópico. Mas antes de passarmos para o próximo tópico, quero abordar algo que podemos encontrar com a pilha de chamadas chamada Stack Overflow. E essa é uma condição que você pode ter enfrentado com sua codificação. Isso ocorre quando a pilha de chamadas é preenchida porque ela não pode remover comandos e outros continuam sendo adicionados a ela. Eu mencionei que funções aninhadas podem adicionar muito à pilha de chamadas. Bem, demora um pouco para a pilha de chamadas seja preenchida. Mas quando ela se enche , causa um erro. Agora, podemos simular isso facilmente com uma chamada recursiva. Agora, recursão é simplesmente quando uma função se chama. E há algumas situações em que esse é um padrão vantajoso em JavaScript. Mas eu quero te mostrar os efeitos do que ele faz na pilha. Então, vamos configurar uma função que ilustre isso. Esse arquivo JavaScript está anexado ao arquivo HTML. Esse aqui que estamos vendo anteriormente. Vou colocar uma função nela e chamá-la de Self Ramus. Veja o que acontece. Então, deixe-me chamar isso de recursão. Não é necessário chamá-lo assim, mas vou fazer isso porque vou chamá-lo. E então eu vou definir o número que é passado em igual a si mesmo mais a si mesmo, algo simples assim. E então é aqui que a recursão acontece. Nós nos invocamos de dentro. Então pense no que isso vai fazer. A pilha de chamadas. Vamos chamar recursão, vai colocar recursão na pilha de chamadas chegar a essa linha. E a recursão será chamada novamente, mas a função não foi concluída, então não foi removida da pilha de chamadas. Outra invocação disso é adicionada à pilha de chamadas. E, portanto, ele continua adicionando recursão à pilha de chamadas até o ponto em que não pode mais adicionar. E é aí que obtemos esse estouro de pilha. Deixe-me ir em frente e invocar isso. Vou passar para o número um. Vamos guardar isso. Agora, como acabei de anexar isso a esse arquivo HTML, vou atualizá-lo e ver o que acontece. Vamos abrir o console e ver o que temos lá. Temos um alcance aéreo não capturado. Nosso tamanho máximo da pilha de chamadas foi excedido. Esse é o ar que receberíamos. Se tivéssemos um estouro de pilha. tamanho máximo da pilha de chamadas foi excedido, e é isso que estamos obtendo lá. Agora, esse é um problema simples de resolver. Tudo o que precisamos fazer é garantir que eventualmente, as funções comecem a ser concluídas, que elas retornem. E então ele pode removê-los da pilha de chamadas. Eventualmente, remova todos eles da pilha de chamadas do crânio. Vamos ver como isso pode ser feito. Digamos que se o número for maior que e eu vou colocar um número grande aqui. Não tenho ideia do tamanho que vai ser, mas se for maior do que isso, vou apenas fazer login no console. Quero ver o tamanho do número, só por diversão. E então eu vou voltar. Então é aqui que estamos retornando dessa função. Então, ele completará a função, retornamos aqui. Não vai fazer isso de novo. E isso completará a função em que estamos. E então ele desenrolará a pilha de chamadas, cada uma dessas funções. Finalmente retornaremos porque isso chegará ao final da função. E então o fato de que a última vez que chamamos isso, onde o, onde num é maior que isso, que força um retorno, não chama outro. E assim, todos os outros que estão na pilha de chamadas também podem ser concluídos. E então não temos esse estouro de pilha. Tudo bem, vamos ver isso só mais uma vez. Vou me refrescar aqui. Quero lembrar que não está ficando maior se eu não devolvê-lo quando chamo essa função. Então, eu quero ter certeza de que está ficando maior. Lá vamos nós. Agora, recebemos um número muito grande saindo e não estamos mais recebendo o estouro de pilha porque conseguimos retornar. Em seguida, desenrole todas as chamadas de função que estão na pilha. Então é a isso que estamos nos referindo quando falamos sobre o StackOverflow. Tudo bem, vamos passar para o próximo tópico. 5. Como entender a coleta de lixo: No tópico anterior, mencionamos a coleta de lixo em conexão com a pilha de memória. Em uma linguagem como C, temos que alocar e liberar memória. Não é assim em JavaScript, mas ainda precisa haver um mecanismo para recuperar memória. Portanto, não ficamos sem memória e travamos o sistema. O Javascript trata da recuperação de memória para nós. Uma vez que uma informação, um objeto ou uma variável, esteja fora do contexto e não seja mais usada. memória é recuperada, então ela pode ser reutilizada. Isso é chamado de coleta de lixo. Vamos dar uma olhada em como isso funciona no motor. coleta de lixo ocorre na pilha de memória e usa o que às vezes é chamado de algoritmo de marcação e varredura. Ele determina os objetos que podem ser excluídos com segurança do calor da memória, determinando quais itens estão acessíveis e quais estão inacessíveis. E então ele varre aqueles que estão inacessíveis. Eles são varridos e essa memória é recuperada. Vamos dar uma olhada em como isso funciona. Agora, o coletor de lixo começa com o objeto raiz ou global e se move para os objetos referenciados por ele. E ele se move de um objeto para outro, identificando coisas que são referenciadas por outra coisa. Então, basicamente, aquelas coisas que são alcançáveis, aquelas que não são alcançáveis agora estão definidas. E então, tudo o que é inacessível, agora vemos algumas coisas que não estão vinculadas ou não acessíveis. Tudo o que está inacessível está limpo. Ele passa e os varre. Eles foram embora. Essa memória agora pode ser recuperada e usada para outra coisa. Agora, como você notou em nossa explicação, ordem para que as informações sejam liberadas e recuperadas não deve estar conectada a nada que esteja acontecendo atualmente no programa, inacessível. Embora seja possível nossa codificação impeça que as coisas sejam recuperadas, mesmo que não as estejamos mais usando. Isso é chamado de vazamento de memória. Vazamentos de memória são partes da memória que o aplicativo precisava e usava no passado e não são mais necessárias, mas seu armazenamento ainda não foi devolvido ao pool de memória. Mesmo que a coleta de lixo seja feita para nós. Como vimos, ainda precisamos ser cautelosos com o gerenciamento de memória. Vazamentos de memória podem fazer com que programas de JavaScript falhem ao usar toda a memória disponível. Vejamos algumas coisas comuns que podem causar vazamentos de memória. Então, primeiro, variáveis globais. Se você continuar criando variáveis globais, elas permanecerão durante a execução do programa, mesmo que não sejam necessárias. Se essas variáveis forem objetos profundamente aninhados, muita memória pode ser desperdiçada. Não remover ouvintes de eventos que não são mais necessários. Como um exemplo de como essa coisa em particular pode acontecer. Você pode criar muitos ouvintes de eventos para uma página ou local específico. E então, quando o usuário ultrapassa isso, onde esses ouvintes de eventos são longos, não são mais necessários. Você, como programador, não os remova. Eles ainda estão lá. Eles ainda estão ocupando memória, especialmente dos objetos aos quais estão vinculados. Então, algo que você deve conhecer. O terceiro item, intervalos de tempo pouco claros. Agora, definir intervalo é um bom exemplo disso. E se você não usou o intervalo definido, basicamente o que ele faz é permitir que você execute algum código repetidamente com base em um determinado período de tempo. Agora, vamos dar uma olhada em um exemplo muito rápido desse. Eu só vou ligar para definir o intervalo. E o intervalo definido toma como primeiro parâmetro uma função. Essa é uma função de retorno de chamada. Portanto, toda vez que o intervalo expira, a quantidade de tempo que inserimos invoca essa função de retorno de chamada. Então, vou configurar uma função aqui. E então o segundo parâmetro é a quantidade de tempo em milissegundos em que cada intervalo acontece. Então, a cada 200 milissegundos, essa função será invocada, ok? Agora, onde isso pode se tornar um problema, digamos, aqui dentro, referenciamos o número de objetos. Esses objetos estão, estão sendo referenciados lá. Às vezes, esse tipo de coisa é feita com animação ou algo parecido. Mas se isso nunca for apagado, se esse intervalo definido não for apagado, obviamente essas referências ainda serão válidas. E, portanto, ele nunca será capaz de liberar essa memória, mesmo que ela não esteja mais sendo usada. Portanto, uma abordagem melhor para o problema do intervalo definido é declarar um ID e definimos esse igual a setInterval, que colocará um ID dentro daqui. Então, quando terminarmos, devemos ter certeza de que temos intervalo claro com esse ID, algo assim. Ok, mais uma coisa que precisamos mencionar : elementos DOM removidos. Se em seu programa você remover elementos do DOM. Mas esses elementos ainda são referência, como em um ouvinte de eventos. Falamos sobre isso antes, ou de alguma outra forma, a memória não será liberada. Outra coisa que você deve conhecer. Agora, revisitaremos alguns desses e outros lugares do curso para que você tenha um lembrete das melhores práticas para evitar vazamentos de memória. Todas essas coisas sobre as quais falamos podem aumentar e os vazamentos de memória continuarão consumindo cada vez mais memória. Se seu programa for executado por tempo suficiente, ele poderá falhar por falta de memória. Mesmo que não caia, você deve evitar vazamentos de memória e não confiar apenas na coleta de lixo para salvar o dia. Tudo bem, vamos passar para o próximo tópico. 6. Como remover ouvintes de eventos para ajudar com a coleta de lixo: Neste segundo tópico sobre coleta de lixo, quero expandir algumas das técnicas específicas dos navegadores mencionados no tópico anterior. Especificamente, abordarei como remover ouvintes de eventos e JavaScript. Nem todos os desenvolvedores de JavaScript estão familiarizados com esse recurso, mas ele é fundamental quando se fala em coleta de lixo. Então, eu queria inseri-lo aqui. Agora, se você estiver codificando para o navegador, estará trabalhando com o amanhecer. O DOM é abreviação de Document Object Model. É simplesmente uma interface que permite ao JavaScript manipular o conteúdo, estrutura e o estilo do documento HTML. O documento HTML é representado usando nós e objetos para que o programador possa interagir e trabalhar com cada elemento na página HTML. Existem vários comandos para trabalhar com o DOM. Eu os abordo detalhadamente em meu curso de introdução e incluí alguns desses tópicos no apêndice. Se você precisar revisar. Incluí informações sobre o DOM e comandos para selecionar e trabalhar com elementos DOM. Tudo bem, agora de volta ao tópico em questão. Se você anexou um ouvinte de eventos a um objeto ou elemento DOM, esse evento não será mais usado. É uma boa prática remover o ouvinte. Então, vamos dar uma olhada no exemplo. Vamos dar uma olhada no código HTML desta página, que estou mostrando no momento. Aqui está, como você pode ver, é uma página HTML bem simples. Temos um título no título, temos alguns CSS. Então, no corpo aqui, temos algumas tags div. E o que eu quero fazer é anexar um ouvinte de eventos a essa tag div aqui que tenha um ID de título. Então, se dermos uma olhada em nosso código JavaScript, como você pode ver, esse app.js está anexado a esse arquivo HTML. Declaramos algumas variáveis aqui. Agora, estou fazendo isso de forma simplista para mostrar um exemplo aqui. Então, eu usei algumas variáveis globais porque é muito simples. Eu não, não vou perder tempo para fazer isso de uma maneira diferente. Eu só quero mostrar esse exemplo. Então, temos algumas variáveis globais aqui. Uma é conta e a outra é uma variável de título que armazena aquela div que tem uma ID de título. É assim que eu o seleciono lá. Então, vamos adicionar um ouvinte de eventos a isso. Então eu venho aqui e simplesmente pego essa variável lá, adiciono ouvinte de eventos. E precisamos indicar qual evento é esse. É um evento de clique que queremos usar. E agora qual função vai chamar Esse é o título? Clique nesta função aqui. Agora, às vezes, você pode adicionar ouvintes de eventos com funções anônimas, onde você declara a função aqui, em vez de declará-la antes de declará-la dentro do ouvinte de eventos de adição. E isso é bom. Mas você precisa estar ciente de que, se fizer isso, você não poderá remover o ouvinte de eventos, caso seja necessário removê-lo, então você deve fazê-lo dessa maneira. Tudo bem. Falarei sobre o motivo disso em apenas um minuto, quando chegarmos a esse ponto. Mas primeiro, vamos ter certeza de que isso está funcionando. Eu vou guardar isso. Eu já tenho o servidor virtual em execução nessa página. Então, eu vou apenas redimensionar isso. E vamos mostrar o console para que possamos ver a mensagem de registro do console quando eu clico no título. E, como podemos ver, aparecer e o contador está aumentando e dizendo tantas vezes que foi clicado. Tudo bem, muito simples. Nós adicionamos o EventListener lá. Agora, vamos ver como removeríamos esse ouvinte de eventos. Então, digamos que aqui, queríamos removê-lo quando a contagem fosse maior que cinco. Então, vamos fazer isso rápido. Declaração If. Se a contagem for maior que cinco. Bem, essa é uma situação em que vamos remover o ouvinte do evento. E aqui está o comando. Temos que usar o mesmo objeto ao qual o ouvinte de eventos está anexado. Nesse caso, é um elemento DOM. Então tidal dot e , em seguida, o comando é remove event, listener, assim. Agora, essa parte dentro dos parênteses aqui deve corresponder ao que tínhamos aqui quando configuramos o EventListener. E é por isso que eu digo que quando você usa a função anônima, você não consegue fazer isso funcionar. Você precisa declarar a função de antemão. Então, essas coisas são as mesmas. E mesmo que você declare opções ou use capture, qualquer outra coisa, ao configurar o addEventListener, você também precisará incluí-las aqui para removê-las. Esse é um dos requisitos desse comando remove event listener. Tudo bem, então vamos em frente e guardar isso. Isso atualizará a página. Você pode ver essas mensagens desaparecidas. Agora, se começarmos a clicar nele, contar, teremos seis. Agora ele deve ser removido. Agora estou clicando nele e nada está acontecendo. Esse ouvinte de eventos foi removido. Então, esse é basicamente o processo de remover um ouvinte de eventos. Queria cobrir isso aqui porque estávamos falando sobre coleta de lixo. Tudo bem, vamos seguir em frente. 7. Como entender o laço do evento: Agora, antes de terminarmos falar sobre o mecanismo JavaScript, precisamos falar sobre o loop de eventos. Até este ponto, estabelecemos que o JavaScript tem um único encadeamento. Ele só tem uma pilha de chamadas. Ele só pode fazer uma coisa por vez, então é síncrono . No entanto, o JavaScript nos permite fazer codificação assíncrona. Um exemplo simples disso é adicionar um botão a uma página HTML. Podemos estar executando um pouco de JavaScript. O usuário clicará no botão e poderemos responder a esse clique. Porque temos o JavaScript em execução fazendo outra coisa. Isso não impede que o usuário clique nesse botão. Obviamente, isso seria uma experiência horrível em um navegador. Outro exemplo é que, se estamos tentando buscar alguns dados de um banco de dados, fazemos essa chamada para o banco de dados e, em seguida, podemos fazer outra coisa enquanto aguardamos o retorno dos dados. Não precisamos esperar por esses dados antes de fazer outra coisa. E isso bloquearia outros processamentos de JavaScript. Nós podemos fazer outra coisa. E então, quando os dados retornam, podemos agir com base nesses dados. Podemos obter essa codificação assíncrona em JavaScript por causa do loop de eventos. No cenário anterior, o comando setTimeout era gerenciado pela API da Web. E eu mencionei nesse ponto, o mecanismo JavaScript esquece tudo sobre isso. Bem, uma vez que esse evento de temporização é concluído, uma vez que a API da web termina no evento de cronometragem, como isso é integrado novamente à pilha de chamadas para que a tarefa que queremos concluir seja concluída. Por exemplo, se você se lembrar, temos uma função de retorno de chamada como parte do setTimeout. Como essa função de retorno de chamada retorna ao mecanismo JavaScript. Vamos examinar o cenário anterior novamente, mas desta vez incluiremos o ciclo de eventos. Mais uma vez. Aqui está nosso código, aqui está nosso setTimeout. E observe que temos uma função aqui. Toda a função tem dentro dela como uma instrução de log do console, só isso. Os milissegundos são definidos como 0, então o cronômetro deve expirar imediatamente. Mas vamos ver o que acontece. Chegamos ao ponto em que a função hello-world é invocada. Então, vamos continuar analisando isso. Portanto, temos a invocação da função hello-world que é adicionada à pilha de chamadas. E então ele começa a trabalhar os comandos dentro dessa função. Portanto, o primeiro comando que encontramos é uma instrução de log do console e registrará a variável a no console. E isso é adicionado à pilha de chamadas. Ele cuida dessa instrução de log. Vemos olá no console. Em seguida, o comando de log do console é removido da pilha de chamadas. E então avançamos nessa função, encontramos o setTimeout. Agora, o mecanismo JavaScript sabe que setTimeout é gerenciado pela API da web, então ele é enviado para lá para ser tratado. Então, a API da web configura um cronômetro. Ele tem a capacidade de executar um cronômetro. E esse cronômetro expira imediatamente porque não definimos como 0 milissegundos. Então, quando o cronômetro expira, o que ele faz com essa função de retorno de chamada? Isso é o que o cronômetro deve fazer. Então, o que ele faz é adicionar a função de retorno de chamada à fila de mensagens. Agora, essa função de retorno de chamada ficará na fila de mensagens e é nesse ponto que o loop de eventos entra em ação. O ciclo de eventos continuará circulando. Ele verificará a pilha de chamadas e verá se ela está vazia. Agora mesmo. Ainda está funcionando na função hello-world. Portanto, não está vazio, mas em ciclos e continua parecendo cena. Se estiver vazio. Se estiver vazio, adicionaria o próximo item disponível na fila de mensagens à pilha de chamadas. Mas agora não está vazio, então precisamos continuar com a função hello-world. Qual é a próxima coisa que aparece? Bem, é outra instrução de log do console, então ela é adicionada à pilha de chamadas. E seguimos em frente e preenchemos a declaração de registro do console World está impressa no console. E assim, essa instrução de log do console é removida da pilha de chamadas. Nesse ponto, terminamos com a função hello-world, que também é removida da pilha de chamadas. Então, como mencionei, o loop de eventos está alternando e verificando a pilha de chamadas. Então, quando verifica e vê, está vazio. Em seguida, ele pega o próximo item na fila de mensagens e o adiciona à pilha de chamadas. E então tiramos essa função anônima, essa função de retorno de chamada, da pilha de chamadas e ela começa a trabalhar com o que essa função precisa fazer. A única coisa nela é uma declaração de log do console. Ele encontra essa instrução de log do console e a adiciona à pilha de chamadas. A instrução de log do console está concluída. Um ponto de exclamação é impresso no console que é removido da pilha de chamadas. Esse é o fim dessa função, e essa função também é removida da pilha de chamadas. E então, neste momento, a pilha de chamadas está vazia, não há mais nada a ser adicionado da fila de mensagens. Então, estamos simplesmente esperando por um número, outro comando JavaScript que precisa ser executado. Tudo bem, agora, antes de terminarmos, deixe-me destacar alguns pontos importantes dessa discussão. Primeiro, outras partes do ambiente JavaScript podem lidar com determinadas tarefas. Por exemplo, aquelas tarefas que pertencem ao navegador. O mecanismo JavaScript não precisa processá-los. Neste exemplo, usamos a API da web para lidar com esse comando setTimeout. Mas os retornos de chamada que fazem parte do que é tratado lá são integrados novamente ao mecanismo usando o loop de eventos. Ele os retira da fila de mensagens e os adiciona à pilha de chamadas. Conseguimos o JavaScript assíncrono dessa forma. O ciclo de eventos é fundamental para que isso aconteça. Outro ponto importante, quando um retorno de chamada é adicionado à pilha de chamadas, o código é tratado pela pilha de chamadas como normalmente seria se o código JavaScript não tivesse vindo do Q, does não importa. Ele processará esse JavaScript da mesma forma. Em seguida, um lembrete de que o loop de eventos está constantemente verificando os itens na fila. E se a pilha de chamadas estiver vazia, se a pilha de chamadas estiver vazia e houver algo na fila, ela adicionará o próximo item disponível da fila à pilha de chamadas. E, como mencionado, a pilha de chamadas é um segmento, portanto, é síncrona. Ele só pode fazer uma coisa por vez, mas sua interação com o loop de eventos e a API da web permite a codificação assíncrona que podemos obter em JavaScript. Tudo bem, vamos passar para o próximo tópico. 8. O ambiente do tempo de execução do nó: Como o NodeJS é uma implementação de JavaScript amplamente usada, acho importante examinar brevemente seu ambiente de execução, especialmente em relação ao loop de eventos e à fila de mensagens que acabamos de falar sobre. Este artigo aborda aqui algumas das vantagens e desvantagens do ambiente Node.JS. E aqui está o URL deste artigo. Você mesmo pode lê-lo, se quiser. Mas eu queria dar uma olhada no diagrama que ele fornece do ambiente de execução. Então, se rolarmos um pouco para baixo aqui, aqui, o node JS Runtime. Agora, algumas dessas coisas que você vai reconhecer, por exemplo, V8, aqui está o motor V8 e ele está lidando com o JavaScript. Isso é o que ele faz. Observe a fila de eventos, nome diferente, mas semelhante à fila de mensagens. O ciclo de eventos também faz parte disso. Para lidar com as coisas na fila de eventos. Esta parte aqui ao vivo, pode-se pensar que, semelhante à API da Web, tratará das coisas que o NodeJS precisa fazer. Isso não é feito por JavaScript, é feito pelo ambiente externo a ele. Portanto, o motor V8 ainda tem um único thread, ainda tem uma pilha de chamadas, mas pode tirar proveito de outras coisas. E rodando em um servidor, há várias coisas diferentes que precisam ser feitas e que serão tratadas aqui. Agora sei que o GIS tem alguns comandos semelhantes aos que vemos no navegador. Por exemplo, setTimeout, set interval, ambos disponíveis e NodeJS também, eles não são manipulados pelo motor V8, assim como não estão em um navegador. Eles são tratados aqui. E, portanto, existem algumas semelhanças. Mas porque é um ambiente diferente, porque o tempo de execução é diferente. Foi tratado de maneiras diferentes, mas os conceitos são transferíveis. Então, mais uma vez, você pode ler mais sobre isso neste artigo, se quiser. Mas eu queria destacar o loop de eventos e as semelhanças entre NodeJS e o ambiente de execução manipulado em um navegador. Tudo bem, vamos passar para o próximo tópico. 9. Iniciação de exercícios: como explorar a pilha de chamadas e o laço de eventos: Então, eu queria fazer um pequeno exercício divertido como parte desta seção, uma chance de explorar um pouco a pilha de chamadas e o ciclo de eventos. Agora, com todos os meus cursos, eu sempre tenho exercícios ao longo deles, porque acho importante você realmente faça coisas para aprender que fazer as coisas precisa ser por conta própria em vezes. E é aí que entram os exercícios. A maneira como faço isso é ter um vídeo inicial apresentando o exercício. E então você vai em frente e experimenta. E então, quando estiver pronto, você vai para o próximo tópico. E passamos por esse exercício. Essa é geralmente a estrutura. Às vezes, eles fazem coisas um pouco diferentes, mas geralmente essa é a estrutura. Então, vamos dar uma olhada no que eu gostaria que você fizesse neste exercício. Tudo bem, os arquivos do exercício e, especificamente, o arquivo JavaScript App.js. Tenho um código aqui e deixe-me explicá-lo bem rápido e depois indicarei o que gostaria que você fizesse. Então, aqui estamos criando uma matriz, e estamos criando uma matriz com 10 mil elementos. O número que eu usei no construtor, o construtor de matriz ali mesmo. E então usamos o método de preenchimento de matrizes para preencher isso com uns. E então, basicamente, ele cria uma matriz com um comprimento de 10 mil que tem uma em todas elas. Isso é o que estamos fazendo aqui. Então eu tenho uma pequena função, eu a chamo de pop it. Basicamente, tudo o que ele faz é simplesmente exibir um valor toda vez que a função é chamada a partir dessa matriz aqui. E então nós o invocamos. E observe que temos recursão aqui porque ela verifica o tamanho da matriz. Se o comprimento ainda for maior que 0, o que significa que ainda há itens nessa matriz, ela se chamará novamente, o que fará com que ele salte outro item. Isso é recursão que estamos fazendo. E, como você se lembra, quando fizemos recursão antes, podemos estourar a pilha. Então, o que eu gostaria que você fizesse é ver qual número é necessário para causar um estouro de pilha. Se 10 mil funcionarem para você, ótimo. Mas pode não ser. E então, jogue com esse número de lances, meio divertido só para ver o que vai fazer com que isso transborde. E então, a segunda parte do exercício, quando você tem essa pilha transbordando, como você pode mudar isso? Como você pode fazer com que isso use o loop de eventos para que a pilha não transborde? Então, é uma ideia interessante, aproveitar algo que está disponível no ambiente de tempo de execução para que não transbordemos a pilha, mas ainda podemos usar o mesmo número que estava transbordando a pilha. Então dê, experimente. Obviamente, eu não ensinei comandos específicos para você fazer isso, embora você tenha visto alguns exemplos ao examinarmos diferentes conceitos nesta seção. Mas experimente com o que você sabe. E então, quando estiver pronto, vá para o próximo tópico e nós o abordaremos. 10. Fim do exercício: como explorar a pilha de chamadas e o laço de eventos: Tudo bem, vamos dar uma olhada neste pequeno exercício divertido aqui. Então, neste momento, 10 mil, são quantos estão nessa matriz. Vamos ver se isso causa um StackOverflow. Então, vou servir isso e ver o que recebemos. Então, vou pular para o arquivo HTML e clicar em Transmitir ao vivo. E depois pulou para o console. No momento, não estamos vendo nenhum erro no StackOverflow. Então, isso parece estar funcionando bem. Então, voltando ao Visual Studio Code, vou reduzir um pouco o tamanho dele para que possamos seguir em frente e ver o registro do console enquanto jogamos com isso. Então, vamos até 10.500. Vamos ver o que acontece lá. Então, vou mudar esse número lá, guardá-lo ainda. Ok. Vamos para 11 mil. Eu vou salvá-lo. E eu ainda não estou tendo problemas. Então, talvez precisemos pular mais. Ainda vamos 13 mil. Ok, vamos 15 mil. E aí temos um transbordamento. Então, eu não sei qual é o número exato, mas isso não era realmente o que eu queria realizar aqui. Eu só queria dar a você a chance de jogar com esse estouro de pilha e ver que, eventualmente, em algum momento, isso fará com que o tamanho da pilha seja excedido. Então temos o alcance do ar não capturado aqui. Tudo bem, então aí está o ar que estamos procurando. Agora. Como podemos mudar isso? Portanto, ainda podemos manter esse número e ainda ser capazes executá-lo recursivamente e retirar todos esses itens da matriz. Bem, para aproveitar o loop de eventos, podemos usar a API da web, podemos usar setTimeout para realmente invocar essa função novamente. Ok? Então, em vez de chamá-lo de recursivo, recursivamente imediatamente, podemos usar setTimeout para invocá-lo. E então, da maneira que faríamos isso, setTimeout, e então passamos a função. Agora, não incluímos os parênteses neste momento porque isso fará com que ele seja invocado imediatamente. Nós apenas passamos a função e ela a invocará assim que o cronômetro expirar. Então, vamos colocar um 0 depois disso por 0 milissegundos que queremos invocar imediatamente. E aqui está nossa nova configuração. Vamos guardar isso e ver o que acontece aqui embaixo. Observe que não estamos recebendo ar. Vamos dar uma olhada na matriz, ver quantas ainda restam. Estamos reduzidos para 13.600. Então, foi assim que muitos surgiram. Então, obviamente, como estamos usando o loop de eventos, estamos usando a API da Web com setTimeout. Para tirá-los. Está demorando mais para remover todos eles porque é necessário configurar esse cronômetro. Em seguida, coloca algo em uma fila. E então esse item da fila é então colocado na pilha de chamadas e, em seguida, é retirado. E está fazendo isso repetidamente. Então, vamos analisar isso contra ele e reduzimos para oh, nós temos 67 mil ou 6700 agora. Então, está passando por eles, mas é meio legal. Você pode ver que ele faz isso porque está fazendo isso muito mais devagar. Mas observe que não está bloqueando. Eu posso inserir coisas aqui no console e não estou impedido de fazer outras coisas em JavaScript. Então essa é a vantagem de o ciclo de eventos funcionar para nós lá. Dê mais uma olhada, quase pronto. E quando eu pressionei Return, estava pronto. Então, agora está limpo dessa matriz. Então, apenas um pequeno exercício divertido para explorar a pilha de chamadas, um pouco de loop de eventos. Tudo bem, vamos passar para o próximo tópico. 11. Como o JavaScript evolui: Como desenvolvedor de JavaScript, é importante entender como o JavaScript evolui e muda. Porque isso é algo definitivo no mundo do JavaScript. Está em constante evolução. Quando comecei a usar o JavaScript, há muitos anos, não era nada parecido com a linguagem que temos hoje. Quase parece um idioma totalmente diferente. Podemos fazer muito mais com isso agora. Para entender como o JavaScript evolui, precisamos falar sobre duas coisas, script ekman e o TC 39. Primeiro, vamos falar sobre o script ECMO. Agora. O que é um roteiro? Tenho certeza que você já ouviu falar disso. É usado o tempo todo, basicamente como uma especificação usada por certos idiomas. É padronizado pela ACM International, e é daí que vem o nome. O Javascript é a implementação mais usada no meu script. É por isso que ele está tão emaranhado com o JavaScript. Mas há outros idiomas dos quais você provavelmente já ouviu falar. A queda desse padrão de scripts Ekman. Por exemplo, Action Script, que é a linguagem por trás do flash baseada no padrão de script Ekman e no script J feito pela Microsoft. Isso também se baseia nessa especificação. Agora, a primeira edição do padrão de scripts Ekman surgiu em junho de 1997, e foi chamada de script Ekman um ou ES1. E desde aquela época, cada lançamento adicional foi , esse número foi incrementado. Então ES x1, x2, x3 e assim por diante. Agora, quando acme script sixth foi lançado, eles começaram a designar o contrato de arrendamento com o ano. E então, naquela época, o lançamento foi tecnicamente chamado de roteiro de Ackman 2015 porque esse é o ano em que o roteiro seis de Ekman foi lançado. No entanto, o ES6 acabou de travar. E então as pessoas se referem a isso como ES6 ou ECMO script 2015. Eles vão e vêm entre isso, porque os lançamentos do ES6 travaram. Esse lançamento em particular foi um grande lançamento com vários recursos para JavaScript. Se você estava no mundo do JavaScript naquela época, você se lembrará de quantas coisas foram adicionadas ao JavaScript. Muitas coisas que agora são usadas regularmente foram adicionadas durante essa versão específica. Agora, desde que essa versão do padrão foi lançada, há um novo lançamento a cada ano. Por isso, tivemos o roteiro de Ekman, 2016201718192020. Todos os anos, um novo lançamento é lançado. Muito disso vem do fato de que o lançamento do roteiro seis de Ekman foi tão grande. Eles não queriam outro lançamento tão grande novamente. E então eles estão abordando o lançamento de uma forma muito mais gerenciável. Agora, quem determina o que há em cada lançamento? De onde vem tudo isso? Bem, isso tem a ver com o TC3 nove. Então, vamos falar sobre isso. Agora. Tc 39 significa comitê técnico 39. E eles são um comitê que desenvolve o JavaScript. E seus membros são empresas como fornecedores de navegadores, esse tipo de coisa que tem um grande interesse em JavaScript. O comitê se reúne regularmente e você pode acompanhar as atas on-line, se desejar. Então, nesse sentido, é transparente. Agora, para que um recurso chegue à maturidade e se torne parte de uma futura versão padrão do script Ekman, esse recurso deve passar por vários estágios e chamamos esses estágios de maturidade. Portanto, o TC3 dynein, o comitê, gerencia essas propostas por meio desses estágios até que sejam aceitas como parte do padrão. Então, eu quero falar sobre esses estágios bem rápido. Então, estágio um ou estágio 0, o primeiro estágio. Mas o estágio 0 é na verdade o estágio de submissão. E isso é apenas o envio de um novo recurso, uma proposta para um novo recurso. E isso deve vir de um membro do TC 39 ou de alguém que seja considerado colaborador do TC 39. E, basicamente, é um documento descrevendo qual é o recurso que eles querem. Esse estágio 0. primeiro estágio é o estágio da proposta. Agora, essa é uma proposta formal para o recurso. E isso deve ter um campeão que como parte desse comitê, alguém que queira que esse recurso seja adotado. Então esse é o estágio um. segunda fase é a fase de rascunho. E essa é realmente a primeira versão do que estará na especificação desse recurso específico. Quando algo chega ao estágio sua eventual inclusão é muito mais provável. Agora, o estágio três é o estágio candidato. Nesse ponto, a proposta está quase concluída e precisa de feedback das implementações e dos usuários. E então, finalmente, o estágio quatro é o estágio final. Neste momento, ele está pronto para ser incluído na especificação e provavelmente será incluído na próxima especificação. Mas isso não é necessariamente uma garantia. todas essas etapas, esses recursos ainda são considerados propostas e não são recursos até que sejam oficialmente incluídos no padrão. Agora, conhecer esses estágios pode ser importante. Por exemplo, se você acessar um site como esse e acessar os recursos futuros, que é feito com próximo botão para descobrir o que é compatível e o que não é compatível. Observe como ele é dividido nos estágios sobre os quais acabamos de falar. Aqui está a fase candidata, aqui está o que está por vir como uma possibilidade no próximo lançamento do roteiro de Ekman. E você pode ver que alguns navegadores e alguns compiladores já estão começando a oferecer suporte a esses recursos propostos. Você pode ver que aqui, à medida que avança nas etapas do rascunho dois, você vê que cada vez menos implementações já foram feitas. E então, como esses fornecedores têm um assento no comitê, eles sabem o que está por vir. Eles podem ser os campeões de uma proposta específica, quem sabe, mas começam a implementar algumas dessas coisas antes de se tornarem parte da especificação oficial. Você pode ver que podemos até ir até o estágio 0, sem muita coisa acontecendo lá. Então, quando artigos ou sites como esse estão falando sobre propostas, propostas de roteiro de Ekman, eles estão falando sobre coisas que estão em um desses estágios que não foram oficialmente adotadas no padrão ainda, mas estão se movendo nessa direção. Então esse é o processo que a treonina tc segue para atualizar o padrão de script Ackman para JavaScript. Tudo bem, vamos passar para o próximo tópico.