Soy un principiante absoluto en el desarrollo de extensiones que intenta comprender el tiempo de ejecución del navegador, que consiste en el bucle de eventos + la pila de llamadas + las API web. Según tengo entendido, si ejecuta un script que contiene una función como esta:
setTimeout(function msg() { console.log("Hey guys."); }, 4000); La llamada a setTimeout() se enviará a la pila de llamadas, se ejecutará y se enviará a la API web, que iniciará el temporizador durante cuatro segundos, después de lo cual se enviará a console.log("Hey guys"); llamada a la cola de bucle de eventos. Solo hasta que la pila de llamadas esté vacía, esta llamada en la cola aparecerá y luego se empujará a la pila de llamadas. Este mecanismo de devolución de llamada es lo que proporciona a los motores de JavaScript una funcionalidad asíncrona.
¿Se aplica el mismo proceso a la siguiente llamada de función?
chrome.runtime.onInstalled.addListener(() => { console.log("Hello"); })Aquí es donde radica mi confusión:
addListener() se inserta en la pila de llamadas, ¿qué sucede después de que se ejecuta? ¿El navegador ahora "almacena" esta función de escucha para que sepa buscar el evento onInstalled ? ¿Y empujará la función de devolución de llamada a la cola de bucle de eventos una vez que se haya detectado el evento?addListener en el objeto de evento chrome.runtime.onInstalled en lugar de tomarlo como un parámetro?chrome.runtime.onInstalled solo una representación del evento real del navegador, no el evento en sí? (es decir, un objeto proporcionado por la API de Chrome)¿Se aplica el mismo proceso a la siguiente llamada de función?
Mas o menos.
Suponiendo que addListener() se inserta en la pila de llamadas, ¿qué sucede después de que se ejecuta?
Cuando se inicia el script, addListener agrega el detector al registro de eventos interno sin llamarlo. El registro se basa en la referencia de la función, por lo que se registrará solo una vez por evento, es decir, las llamadas addListener subsiguientes se ignorarán de manera efectiva.
Luego, el script finaliza, todos los oyentes están registrados.
Luego, en caso de que esta secuencia de comandos sea la secuencia de comandos en segundo plano no persistente (trabajador de servicio o una página de eventos), el evento que despertó la secuencia de comandos en segundo plano se usará para encontrar sus oyentes registrados en el registro y se les llamará. Esta es la razón por la que la documentación dice que los oyentes de API deben estar registrados en el "nivel superior", aunque es una simplificación excesiva. Técnicamente, los oyentes deben estar registrados antes de que finalice el script, es decir, puede ocurrir dentro de una función anidada siempre que se ejecute sincrónicamente, e incluso dentro de un módulo ES importado sincrónicamente .
¿Por qué se llama al método addListener en el objeto de evento?
Así es como la API de extensiones se implementa internamente, no hay una razón universal por la que se usó esta forma exacta, así es como les gustó y tiene mucho sentido porque el objeto contiene varios métodos útiles como hasListener , removeListener y varios otros .
¿Es el objeto chrome.runtime.onInstalled solo una representación del evento real del navegador, no el evento en sí?
La palabra "evento" aquí no significa una instancia del evento similar al objeto DOM Event que se envía al código JS. No existe tal cosa en la API de extensiones. Es solo una parte estática de la API anidada para representar la estructura de la misma: chrome es el espacio de nombres común, runtime es la API específica, onInstalled es el nombre del evento. Este objeto está construido por la capa JS interna de la plataforma de extensiones cuando se inicia el script.