Video Summary and Transcription
La charla de hoy explora varias APIs Web y sus funcionalidades, incluyendo la API de Observador de Intersección para la visibilidad de elementos, la API de Red para la detección de conexiones, y la API de Sincronización en Segundo Plano para capacidades offline. La API de Canal de Difusión permite la comunicación entre componentes y el Beacon, las APIs de Discurso Web, Compartir Web, Bloqueo de Pantalla en Vigilia, Visibilidad de Página, Recogida en Segundo Plano y Autenticación Web ofrecen funcionalidades adicionales. Estas APIs estandarizadas funcionan en todos los navegadores y pueden mejorar el rendimiento mientras reducen el consumo de electricidad.
1. Introducción a las Web APIs y Ejemplo del Astronauta
Hoy vamos a hablar sobre las Web APIs y sus funcionalidades proporcionadas por el navegador. Podemos aprovechar estas interfaces incorporadas para mejorar nuestras aplicaciones web. Vamos a explorar algunas APIs nuevas o no tan conocidas que ofrecen superpoderes. Soy Nikola Mitrovic, Líder de Desarrollo e Ingeniero de Software en Vega IT. En nuestro primer ejemplo, tenemos una página con un pequeño astronauta que muestra un mensaje cuando es completamente visible mientras se desplaza.
¡Hola React Advanced Londres! Bienvenidos a la charla de hoy. Les doy una cálida bienvenida. Hoy vamos a hablar de algo llamado Web APIs. Pero antes de hacer eso, necesitamos dar un pequeño paso atrás y volver a algunos conceptos básicos de JavaScript. Probablemente esta es una pregunta clásica de entrevista y si les pregunto cuál es la respuesta, la mayoría de ustedes diría que el orden de estos registros sería 1, 3, 2, ¿verdad? Pero, ¿cómo saben eso? ¿Cómo podemos saber eso? Así que vamos a visualizar un poco este ejemplo y a comprobarlo.
Como sabemos, hay una pila de llamadas. Nuestro motor comienza a ejecutar línea por línea. Console.log es asincrónico y se ejecuta inmediatamente, pero el set timeout es asincrónico, así que necesita dar una vuelta. Espera un número de milisegundos que ponemos en un callback. Va a la cola. Esperamos que la pila de llamadas esté libre de nuevo, y luego el bucle de eventos se activa con el valor que nosotros pusimos dentro del callback. Pero la pregunta es, ¿dónde espera setTimeout esos número de milisegundos? Y la respuesta es, WebAPI. Si eres un ingeniero curioso como yo, podrías preguntar en ese punto, OK, ¿qué es la WebAPI? Y si buscamos un poco en Google, podemos descubrir que hay una documentation de MDN sobre WebAPI, y el setTimeout está bajo la pestaña, WebAPI. Si revisamos allí, podemos ver que hay una serie de funcionalidades disponibles que los navegadores nos ofrecen de serie. Y si exploramos un poco allí, podemos encontrar muchas APIs conocidas. Como, por ejemplo, si alguna vez construiste un componente de carga de archivos, si alguna vez usaste geolocalización, si alguna vez te comunicaste con alteraciones de elementos DOM, si usaste almacenamiento local, almacenamiento de sesión. Así que todas esas APIs son funcionalidades que son proporcionadas por el navegador. Por supuesto, hay algunas APIs conocidas y algunas funcionalidades conocidas que estás usando en tu trabajo diario. Pero me preguntaba cuáles son algunas de las nuevas APIs o las no tan conocidas que podemos aprovechar en nuestras aplicaciones web y realmente usar estos superpoderes? Así que podemos concluir que WebAPI es una colección de esas interfaces incorporadas que podemos usar simplemente utilizando el navegador.
Primero, me presentaré rápidamente. Mi nombre es Nikola Mitrovic. Trabajo como Líder de Desarrollo e Ingeniero de Software en Vega IT, con sede en Novi Sad, Serbia. Y estos son mis destacados de WebAPI para ustedes para hoy. Vamos a nuestro primer ejemplo para hoy. Digamos que tenemos una aplicación como esta. Tenemos una página. Cuando nos desplazamos un poco hacia abajo, entonces empezamos a notar que hay un pequeño astronauta en la parte inferior, en la esquina. Y si nos desplazamos un poco más, una vez que el astronauta es completamente visible, dice: Hola Mundo. Si nos desplazamos un poco hacia arriba y el astronauta no es completamente visible, el mensaje desaparece. Si nos desplazamos un poco hacia abajo de nuevo,
2. Uso de la API Intersection Observer
La API Intersection Observer ayuda a determinar si un elemento es visible en la página al verificar si se cruza con el viewport. En React, podemos crear un hook llamado UseVisible para observar elementos. Este hook toma una referencia al elemento y un objeto de configuración para el Intersection Observer. Podemos establecer el margen y el umbral para la intersección. Al establecer el umbral en 1, observamos cuando el elemento está completamente visible. El hook devuelve una variable de estado, isVisible, que indica si el elemento es visible o no.
él dice de nuevo, Hola Mundo. Bien, ¿cómo logramos hacer esto? Existe una API llamada Intersection Observer API, que básicamente determina si el elemento es visible en la página o no, si está intersectando el viewport. Si estamos haciendo esto dentro de un React, probablemente construiríamos un hook, llamémoslo UseVisible y el código se vería así. El hook acepta dos parámetros, uno es la referencia de un elemento que estamos intentando observar y hay un objeto de configuración para el Intersection Observer. Esa configuración puede tener el ancestro del objetivo, si pasamos el null, entonces estamos asumiendo que estamos usando el viewport como un elemento padre. Podemos establecer el margen alrededor de ese elemento y llamar a esa intersección un poco antes, y hay un umbral que es un número del 0 al 1. Como lo establecimos en 1, observamos cuando un elemento está completamente visible, por lo que podemos intersectar digamos a la mitad de la visibilidad. Tendríamos un estado isVisible, por supuesto, y luego instanciamos un objeto observador de intersección. Dentro de un callback obtendríamos un objeto de entrada, y esa entrada tiene una propiedad llamada isIntersecting. Así que, básicamente, en base a eso, podemos averiguar si el elemento es visible o no, ese valor sería verdadero o falso. Lo que queda por hacer es simplemente observar ese elemento. Y luego al final, por supuesto, establecemos el estado y lo devolvemos, y obtendríamos de ese hook simplemente
3. Casos de Uso Reales y Soporte de Navegador
Podemos usar la API Intersection Observer en casos de uso reales como la carga diferida de imágenes, la creación de listas de desplazamiento infinito y la diferimiento de animaciones. Es importante considerar el soporte del navegador, pero en este caso, todos los principales proveedores admiten esta API.
estado verdadero o falso. Este ejemplo con Astronauta fue lindo y divertido, pero probablemente te estés preguntando cómo podemos usar esta API en algunos casos de uso reales. Podríamos usarlo para cargar imágenes de manera diferida. Entonces, por ejemplo, solo podemos cargar lo que es importante cargar inicialmente para la aplicación. Y podemos descargar y cargar imágenes de manera diferida. Una vez que volvemos a desplazarnos a cierta sección que contiene imágenes. Podríamos crear listas de desplazamiento infinito. Entonces no necesitamos una biblioteca para esto. Por ejemplo, podemos tener una lista de 10 elementos y podemos tener el final del elemento de la lista. Y una vez que desplazamos y ese elemento es visible, significa que llegamos al final de la lista y luego podemos disparar la próxima solicitud. Podríamos diferir algunas animations. No necesitamos ejecutar algunas animations si no son visibles en la pantalla, y en ese sentido, podemos ahorrar algo de energía de la computadora.
Una de las cosas que siempre debemos considerar al usar algunas de estas APIs web es el soporte del navegador. Entonces, todos los principales proveedores admiten este estándar de APIs web, pero no todos ellos están implementando, tienen esa implementación en su lugar. Pero en este caso, podemos ver que todos los principales proveedores admiten esta API, por lo que estamos listos para continuar y podemos usar esto y aprovecharlo dentro de
4. Uso de la API de Red y React Hook
En el siguiente ejemplo, tenemos una aplicación llamada semirco.rs que se comunica con la API de la NASA para proporcionar una lista de exoplanetas habitables. Podemos buscar un planeta y reservar un vuelo. La API de Red nos ayuda a detectar cambios en la conexión del sistema y reaccionar en consecuencia. Al crear un hook llamado UseNetwork, podemos verificar el tipo de conexión y devolver el estado. También podemos rastrear cambios en la red y ejecutar cambios de estado. Los casos de uso incluyen notificaciones al usuario y precarga de recursos. Los navegadores basados en Chrome admiten esta API, pero Firefox y Safari no.
nuestras aplicaciones web. Ahora pasamos al siguiente ejemplo. Aquí tenemos una aplicación un poco futurista llamada semirco.rs que traducida al inglés significa astronauta. Es una aplicación que si vamos a en el backend estamos comunicando con la API de la NASA que nos devuelve la lista de todos los exoplanetas habitables posibles. Y luego podemos ir y buscar un planeta al que queremos visitar para unas vacaciones o para disfrutar y por ejemplo está este TOI-1136G, eso suena increíble, siempre quisimos ir allí y luego podemos hacer clic para reservar un vuelo a ese planeta. Después de algún tiempo, el vuelo está reservado, pero ¿qué pasa si tenemos problemas de conectividad? Así que intentamos reservar un vuelo y esa solicitud tarda un poco. Después de algún tiempo podemos mostrar un mensaje para tener una mejor UX o algo y una vez que la conexión rápida se activa podemos quitar ese mensaje. Así que ten en cuenta que no se trata solo del tiempo de la solicitud, también se trata de reaccionar a los cambios de red. Entonces, ¿cómo podemos hacer esto? Hay una API llamada API de Red por supuesto que proporciona información sobre la conexión del sistema y también detecta cambios de conexión que acabamos de ver. Si estamos construyendo esto en React, probablemente haríamos un hook llamado UseNetwork. Tendríamos el estado que representa si la red es rápida o no. Luego verificamos el objeto de conexión dentro de un navegador. Voy a volver a esto por qué esto es importante pero si hay un objeto de conexión, hay un objeto EffectiveType en ese objeto de conexión y luego podemos verificar el valor de ese EffectiveType. Los valores posibles de ese EffectiveType son Slow2G, 2G, 3G y 4G. Entonces podemos asumir que si es 4G entonces, está bien, es una red rápida, si es algo de lo contrario, lo consideramos como una red lenta. Y simplemente devolvemos ese estado desde el hook. Como mencionamos antes, también podemos react a los cambios en la red. Así que de nuevo vamos al objeto de conexión dentro de un navegador y añadimos EventListenerChange para que podamos rastrear esos cambios de red. Una vez que hay un cambio podemos ejecutar de nuevo un cambio de estado. ¿Cuáles son algunos de los casos de uso? Por supuesto, algunas notificaciones a los usuarios o la precarga de grandes recursos. Esto es importante para el performance, así que podemos verificar si la conexión de red es rápida. Si es rápida, entonces podemos precargar algunos recursos más grandes. De nuevo, si miramos el soporte del navegador para estos. Bueno, ahora aquí la situación es un poco diferente. Los navegadores basados en Chrome admiten esta API, pero Firefox y Safari aún no están allí, así que tendremos que esperar un poco para usar esta API en todos los navegadores.
5. Aplicación Offline y Sincronización en Segundo Plano
En el siguiente ejemplo, exploramos el escenario de una aplicación offline. Al intentar acceder a una página que desencadena una solicitud a la API de la NASA, no ocurre nada si estamos offline. Sin embargo, en la pestaña de la aplicación, hay una función de sincronización en segundo plano que registra un evento cuando volvemos a estar online. Este evento desencadena la solicitud y devuelve la lista de planetas habitables.
Bien, pasemos al siguiente. De nuevo, tenemos un ejemplo con swamirco.rs, pero en el ejemplo anterior, no cubrimos uno de los casos de uso más esenciales al usar las aplicaciones web de hoy en día, y eso es ¿qué pasa si nuestra aplicación se queda offline? Sé que esta es una aplicación de dentro de unos miles de años, pero digamos que todavía tenemos problemas de conectividad a veces. Y si intentamos ir a esa página, una vez que pasamos el cursor sobre este botón, estamos desencadenando la solicitud a la API de la NASA. Pero si vamos a la pestaña de red, no está pasando nada. Así que en circunstancias normales, esperaría que hubiera una solicitud de red que falló, y vería una solicitud roja aquí que falló. Pero aquí podemos ver que no pasa nada. Si intentamos ir a esa página, podemos ver que hay un cargador que sigue cargando los data, pero sabemos que todavía estamos offline. Curiosamente, dentro de la pestaña de la aplicación hay algo llamado sincronización en segundo plano, y una vez que paso el cursor sobre ese botón, puede que te des cuenta de que se desencadenó un evento aquí, y eso es un evento de registro. Una vez que volvemos a estar online, hay un evento de despacho, y luego desencadenamos la solicitud a la API de la NASA. Una vez que la solicitud ha terminado, entonces tenemos un tercer evento llamado evento de sincronización completada, y ahora obtenemos la lista de
6. API de Sincronización en Segundo Plano y Capacidades Offline
Existe una API llamada API de sincronización en segundo plano que nos permite diferir tareas en segundo plano mientras estamos offline. Al registrar un evento de sincronización basado en una etiqueta, podemos continuar con nuestra solicitud una vez que el Service Worker recibe el evento. Esta API es útil para capacidades offline y tareas como enviar correos electrónicos. Sin embargo, Firefox y Safari tienen un soporte limitado para esta API.
todos los planetas habitables que teníamos antes. Bien, ¿cómo logramos hacer esto? Existe una API llamada API de sincronización en segundo plano, que proporciona una forma de diferir algunas tareas en segundo plano mientras estamos offline en un Service Worker. Este es el componente que tenemos en nuestra primera página con el enlace, y una vez que pasamos el cursor sobre el enlace, entonces podemos registrar esa sincronización en segundo plano. Dentro de un navegador hay un objeto Service Worker y hay una propiedad ready. Una vez que llegamos a esa registración, entonces podemos registrar ese evento de sincronización basado en una etiqueta. Ahora, esta etiqueta es importante porque podríamos tener múltiples eventos, múltiples tareas ejecutándose en segundo plano mientras estamos offline. Y dentro de un Service Worker, simplemente esperamos el evento de sincronización y comprobamos el nombre de la etiqueta. Si es el mismo, entonces continuamos con nuestra solicitud. Algunos de los casos de uso para esta API, por supuesto, capacidades offline o tal vez si queremos enviar un correo electrónico mientras estamos offline, ya hemos hecho clic en el botón. El soporte del navegador en este caso, de nuevo, es el mismo que antes. Tendríamos que esperar un poco para
7. Comunicación con la API de Canal de Transmisión
Para comunicarnos entre un Service Worker y nuestros componentes, utilizamos la API de Canal de Transmisión. Esta API permite la comunicación entre los mismos contextos de navegación, como ventanas, pestañas, marcos o iframes. Abrimos un canal, nos conectamos a él y utilizamos el método postMessage para enviar mensajes. Dentro de nuestro componente, nos suscribimos al canal y escuchamos el evento onMessage. Esta API tiene varios casos de uso, como detectar acciones del usuario y cerrar sesión en todas las pestañas. Es compatible con todos los navegadores.
Firefox y Safari para mantenerse al día con esto. Si te estás preguntando cómo logramos comunicarnos entre un Service Worker y nuestros componentes, en el ejemplo anterior, una vez que hemos establecido la conexión, buscaríamos nuestro planeta habitable. Eso sería una solicitud a la API de la NASA, y extraemos el cuerpo de esa respuesta. ¿Y cómo logramos llevar esa lista al componente, a un componente React? Existe una API llamada API de Canal de Transmisión, que básicamente permite la comunicación entre los mismos contextos de navegación, lo que significa la misma ventana, pestañas, marcos o iframes. La parte importante es que todos están en el mismo origen. Y la comunicación va en ambos sentidos. ¿Cómo podemos hacer eso? Abrimos un canal. Nos conectamos a un canal basado en un nombre, y luego hay un método postMessage en ese objeto para enviar el mensaje. Y podemos enviar cualquier tipo de estructura u objetos. Dentro de nuestro componente, nos suscribimos a ese mismo canal, y hay un evento onMessage, que nos proporcionará esos datos. Casos de uso para esta API. Podemos detectar algunas de las acciones del usuario, o tal vez podemos cerrar sesión en todas las pestañas si cerramos sesión en nuestra aplicación. El soporte del navegador, en este caso, está todo bien.
8. APIs web geniales y su impacto
Hoy exploramos algunas APIs geniales como Beacon, Web Speech, Web Share, Screen Awake Lock, Page Visibility, Background Fetch y Web Authentication. Estas APIs estandarizadas funcionan en todos los navegadores y pueden mejorar el rendimiento al reducir el tamaño del paquete. Es importante considerar el soporte del navegador y del dispositivo al usar estas APIs. Además, el uso de las APIs web en lugar de las bibliotecas puede contribuir a un web más verde al reducir el consumo de electricidad. ¡Gracias por acompañarnos hoy!
Entonces podemos usar esta característica en todos los navegadores para todos los usuarios, lo cual es increíble. Y dado que tenemos un tiempo limitado hoy, desafortunadamente, tendríamos que parar. Pero voy a darles algunos puntos extra y espero haberles despertado suficiente interés para investigar algunas de estas geniales APIs por su cuenta. Así que aquí están mis destacados. Hay una API Beacon que básicamente usamos si quieres enviar una solicitud, pero no te importa la respuesta. El caso de uso son algunas analíticas. Hay una API de Web Speech, que puede descifrar nuestra charla y incluso darnos algunos diagnósticos sobre ciertas palabras. Hay una API de Web Share, que nos ayuda a compartir data entre diferentes dispositivos. Hay una API de Screen Awake Lock, que nos impide bloquear la pantalla en nuestros dispositivos, a pesar de las preferencias personales de ese dispositivo. Hay una API de Page Visibility, que averigua si todo el navegador, si toda la pestaña es visible o no. Hay una API de Background Fetch, que es básicamente similar a Background Sync, pero si estamos descargando algunos recursos grandes y nos quedamos sin conexión. Y por supuesto, hay una API de Web Authentication, que es una nueva y brillante API web para la autorización sin contraseña y la authentication, por supuesto. Y algunas de las conclusiones. Hemos visto que con algunas de las APIs, no existe soporte de navegador existente. Así que todavía podemos tener algunos desafíos al usar algunas de estas APIs web. Algunas de ellas tienen soporte experimental de navegador por lo que tienen alguna implementación en marcha, pero tal vez no esté lista para producción. Algunas de ellas tienen soporte de dispositivo, por ejemplo, como la API de Screen Away Clock. Así que hay algunos desafíos, y debemos tener cuidado al usar algunas de las APIs. Pero, ¿por qué deberíamos hacer esto, y por qué deberíamos tomar este enfoque? Porque es código estandarizado, es código estandarizado, es código estandarizado. Probablemente no podría enfatizar lo suficiente lo importante que es esto, especialmente en el web development de hoy en día donde tenemos una nueva biblioteca o un nuevo marco cada semana. Esto es algo así como una única fuente de verdad. Estas APIs están estandarizadas, y funcionan en todos los navegadores de la misma manera desde la perspectiva del código. Así que ese código es bastante estandarizado y no debería romperse en un futuro próximo. La mayoría de estas APIs son fáciles de aprender, no son super complicadas o algo así. Y pueden aumentar el performance porque si nosotros adoptamos esta mentalidad de usar las APIs y no tantas bibliotecas, o construir algo por nuestra cuenta basado en algunas de estas APIs como hemos visto para las listas de desplazamiento infinito, el tamaño del paquete de nuestra aplicación será menor. Y eso me lleva a mi próximo punto, por qué es tan importante, especialmente con el performance y los tamaños de los paquetes. Quería hablar un poco sobre nuestro planeta. Si tienes 4 o 4 expresiones faciales ahora mismo, como, ¿qué? ¿De qué estás hablando? En realidad, cuando construimos nuestra aplicación, obtenemos un cierto paquete de JavaScript, que empujamos en algún lugar a algún servidor, esos servidores a algunos proveedores de cloud, que están repartidos por todo el mundo, y todos esos servidores usan mucha electricidad. De hecho, tanto que Internet consume el 21% de toda la electricidad del mundo. Afortunadamente para nosotros, hay un sitio web llamado Website Carbon Calculator, que averigua todo esto por nosotros. Básicamente, comprueba cuán verde es nuestro sitio web. Esto es super importante porque realmente odiaría si tuviéramos que usar swmirko.rs para correr por nuestras vidas y no para ir de vacaciones o disfrutar de nosotros mismos. Así que, por favor, sean amables con nuestro planeta y usando algunas de las APIs web y no usando las bibliotecas y aumentando los tamaños de los paquetes son una de las muchas formas en que podemos hacer esto. Si unimos fuerzas juntos, no tiene que ser un gran esfuerzo, pero si todos nos unimos un poco, todos podemos producir un gran, gran resultado en este sentido. Así que, muchas gracias por estar con nosotros hoy, espero que les haya gustado esta charla. Si necesitan un repaso, hay un código QR, que es el enlace a las diapositivas mismas. En la parte inferior, hay un enlace a mi GitHub, donde pueden revisar todas las APIs, todos los ejemplos por ustedes mismos, ejecutarlos localmente, tal vez modificarlos un poco. Avísenme si tienen algunas mejoras, por supuesto. Y eso sería todo. Muchas gracias.
Comments