Superpoderes de la API Web del navegador

¡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,

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

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

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.