Cuando escribimos código para la Web, hay muchas capacidades que se ofrecen de serie por nuestros navegadores. Si alguna vez escribiste un componente de Carga de Archivos, usaste temporizadores e intervalos, interactuaste con el DOM, o almacenaste algo en el Almacenamiento Local/De Sesión, tuviste que ir a los documentos de la API Web de MDN, para encontrar información relevante sobre cómo implementar ese código. En esta sesión, nos adentraremos en el emocionante mundo de las APIs Web del navegador que no se utilizan tan comúnmente (aunque deberían serlo) y exploraremos sus increíbles capacidades 🚀 Todas estas características ofrecen nuevas oportunidades para crear experiencias web inmersivas que pueden ayudar a las empresas a crecer y conectar con los clientes. Así que si eres el tipo de ingeniero que quiere estar por delante de la curva en lo que respecta al desarrollo web, aprende cómo el Observador de Intersección, la API de Sincronización en Segundo Plano, la API de Bloqueo de Pantalla (y muchas más) pueden ayudarte a crear mejores aplicaciones web que mantendrán a los usuarios enganchados y volverán por más!
This talk has been presented at React Day Berlin 2023, check out the latest edition of this React Conference.
FAQ
Una API web es una lista de funcionalidades proporcionadas por el navegador que permite realizar diversas operaciones más allá de las capacidades básicas del JavaScript, como manejar temporizadores con setTimeout.
setTimeout es una función que ejecuta un bloque de código después de un tiempo especificado en milisegundos. Primero espera el tiempo definido y luego se ejecuta el código en la pila de llamadas, siempre y cuando la pila esté vacía.
La API del observador de intersección permite detectar cuándo un elemento específico entra o sale de la zona visible de la pantalla. Se utiliza para realizar acciones como cargar contenido dinámicamente o iniciar animaciones solo cuando el usuario puede ver el elemento.
La Screen Wake Lock API es una funcionalidad que permite evitar que la pantalla del dispositivo se apague automáticamente cuando está inactiva. Es útil en situaciones como la lectura de un libro electrónico o la visualización de una receta en la cocina.
La API de sincronización en segundo plano permite registrar tareas que se ejecutarán cuando el dispositivo vuelva a estar en línea. Esto es útil para manejar acciones como sincronización de datos o envíos de formularios que se realizaron mientras el dispositivo estaba desconectado.
La Broadcast Channel API permite la comunicación entre diferentes partes de una aplicación web que comparten el mismo origen. Esto es útil, por ejemplo, para sincronizar estados o realizar acciones en todas las pestañas abiertas de una aplicación simultáneamente.
Los principales desafíos incluyen la falta de soporte uniforme entre navegadores, las diferencias en la implementación de las APIs y la necesidad de realizar pruebas exhaustivas para asegurar la compatibilidad y el funcionamiento adecuado en todos los entornos de usuario.
La charla de hoy cubre varias APIs web y sus funcionalidades, incluyendo la API de observador de intersección, la API de bloqueo de pantalla, la API de sincronización en segundo plano, y la API de canal de transmisión. El orador enfatiza la importancia de optimizar el rendimiento y utilizar código estandarizado para reducir el tamaño del paquete de la aplicación. También destacan la necesidad de responsabilidad medioambiental en el desarrollo de JavaScript. La charla aborda el manejo del soporte de la API y la modificación del código para adaptarse a diferentes implementaciones de navegadores.
Hoy vamos a hablar sobre la API web y sus funcionalidades proporcionadas por nuestros navegadores. Antes de eso, repasemos algunos conceptos básicos de JavaScript. Discutiremos el bucle de eventos y cómo funciona setTimeout. setTimeout es una API web proporcionada por el entorno de ejecución. Vamos a explorar algunas APIs menos conocidas y sumergirnos en el mundo de la API web.
Les doy una cálida bienvenida a la conferencia de hoy y a la charla de hoy. Muchas gracias por estar aquí hoy. Hoy vamos a hablar sobre algo llamado API web. Pero antes de hacer eso, necesitamos dar un pequeño paso atrás e ir a algunos conceptos básicos de JavaScript. ¿Alguien puede decirme cuál sería la salida de este código? ¿Alguien? No sean tímidos. 132. Muy bien. ¿Puedo preguntarte cómo sabes eso? Vale, eso es correcto. Eso está genial. Entonces mencionaste que hay un bucle de eventos, ¿verdad? Pero antes de que setTimeout vaya al bucle de eventos, tenemos un paso intermedio. Vamos a visualizar este ejemplo un poco. Tenemos la primera llamada, ¿verdad? Que es sincrónica. Llegamos a la pila de llamadas y se ejecuta inmediatamente. Luego tenemos una segunda llamada que es asíncrona que necesita ir a algún lugar y esperar el número de milisegundos que pusimos. Y luego va al bucle de eventos, ¿verdad? Y luego tenemos una tercera llamada que se ejecuta, de nuevo. El bucle de eventos verifica si la pila de llamadas está vacía y luego esa devolución de llamada en el setTimeout se empuja a la pila de llamadas y se ejecuta entonces. Pero la pregunta es ¿dónde? ¿Dónde espera setTimeout ese número de milisegundos que pusimos? Así que cuando estábamos anunciando la conferencia, algunos de los oradores decían que una de las mejores cualidades que podemos tener como ingenieros es ser curiosos. Así que si eres tan curioso como nosotros, probablemente irías a Google y buscarías esto. Y el primer enlace que podríamos tener es este setTimeout de la documentación de MDN. Si hacemos clic en eso, podemos ver la especificación sobre la función setTimeout y podemos aprender todo sobre ella. Pero podemos ver que está bajo la pestaña llamada APIs web. Si hacemos clic en eso, podemos ver que en realidad setTimeout es una funcionalidad proporcionada por el runtime y no por JavaScript per se, lo que significa que el entorno en el que ejecutamos nuestro JavaScript nos está proporcionando esta funcionalidad. Y como podemos ver, hay muchas funcionalidades proporcionadas por nuestros navegadores. Probablemente reconocerás la mayoría de estas, como la API DOM o la API Fetch o el almacenamiento local, el almacenamiento de sesión, los trabajadores de servicio. Así que probablemente has usado muchas de estas APIs. Pero estaba explorando esta lista, y me preguntaba, ¿cuáles son algunas de las no tan conocidas, exóticas, digamos, APIs que podríamos usar pero que no estamos usando en nuestro trabajo diario? Así que básicamente eso es lo que estamos tratando de explorar hoy. Así que la respuesta a esta pregunta es la API web. setTimeout es una API web. Y ya hemos visto que básicamente la API web es como una gran lista de funcionalidades proporcionadas por nuestros navegadores. Voy a presentar rápidamente
2. Introducción a la API del Observador de Intersección
Short description:
Cuando estaba en la escuela secundaria, siempre quise estudiar psicología. Ahora trabajo como líder de desarrollo, enseñando a las personas cómo lidiar con el estrés, comunicarse con los clientes y hacer presentaciones técnicas. Hoy, compartiré mis superpoderes de las APIs web. Comencemos con un ejemplo utilizando la API del observador de intersección para determinar si un elemento es visible en una página. Podemos usar esto en nuestros proyectos y presentaciones de la vida real.
yo mismo. Cuando estaba en la escuela secundaria, siempre quise estudiar psicología. Ahora trabajo en mi trabajo soñado como líder de desarrollo, donde enseño a las personas cómo lidiar con el estrés, cómo comunicarse con un cliente, cómo hacer presentaciones técnicas, obviamente, y cosas así. Y por supuesto soy ingeniero de software en Vega IT. Mi nombre es Nikola Mitrovic. Estos son mis superpoderes de las APIs web para ustedes hoy. Bien. Vamos a nuestro primer ejemplo de hoy. Digamos que tenemos una página como esta, que es como una página vacía y solo tiene un fondo. Pero una vez que desplazamos, empezamos a observar algo en la esquina inferior izquierda. Es un pequeño astronauta, y una vez que ese astronauta es completamente visible, dice, hola mundo. Desplazamos un poco hacia arriba, y de nuevo, el mensaje desaparece. Desplazamos un poco hacia abajo, y el astronauta dice de nuevo, hola mundo. Entonces, ¿cómo logramos hacer esto? Hay una API muy interesante llamada API del observador de intersección que básicamente determina si el elemento es visible en una página o no. Si nosotros construiríamos un hook en React para esto, probablemente lo llamaríamos algo como use visible, y se vería algo así. Pasaríamos una referencia de un elemento que estamos tratando de observar. En nuestro caso, era el icono del astronauta. Y hay algunas opciones, opciones de configuración, que podríamos proporcionar al observador de intersección. Una de esas opciones es el elemento raíz. Entonces, si pasamos null, observamos la visibilidad de un elemento comparando con todo el documento. Así que podemos observar la visibilidad comparando con algún otro elemento, como un elemento interno o un contenedor interno o algo así. Podríamos poner un margen raíz alrededor de eso. Entonces, si queremos capturar esa intersección un poco antes, y hay un cierto umbral, así que queremos un 100% de visibilidad en este caso, pero podríamos modificar eso. Tendríamos un estado como es visible, ¿verdad? Y luego instanciamos el observador de intersección. En la devolución de llamada, podríamos ver que hay un objeto de entrada. Y en ese objeto de entrada, hay una propiedad llamada is intersensing. Una vez que hacemos eso, podemos establecer nuestro estado y lo único que queda por hacer es observar ese elemento. Y prácticamente eso es todo. Y devolvemos ese estado. Por supuesto, el ejemplo que mostré con el astronauta era lindo o algo así. Pero probablemente te estás preguntando cómo podemos usarlo en nuestros proyectos reales en nuestras presentaciones reales.
3. Optimizando el Rendimiento y Anécdota Personal
Short description:
Podemos cargar imágenes de forma perezosa, hacer listas de desplazamiento infinito y diferir animaciones para optimizar el rendimiento. El soporte del navegador para estas APIs web es bueno, lo que las hace seguras de usar. En nuestro próximo ejemplo, configuraré mi portátil para que se apague después de un minuto de inactividad. Permíteme hablar un minuto sobre mí. Me encanta viajar, especialmente a Italia. La arquitectura, la gente y la comida son increíbles. Disfruto preparando recetas italianas en casa. Veamos si mi dispositivo se apaga después de un minuto de inactividad.
Podríamos cargar imágenes de forma perezosa, por lo que no tenemos que cargar cada parte del contenido en la página inicialmente, y podemos hacer alguna performance optimization. Entonces, una vez que desplazamos a una cierta sección, entonces cargamos imágenes para esa sección. Podríamos hacer listas de desplazamiento infinito, ¿verdad? Así que digamos que tenemos una lista de 10 elementos, y ponemos como un elemento vacío al final de esa lista. Desplazamos un poco. Una vez que eso es visible, activamos la siguiente solicitud y así sucesivamente. Podríamos diferir algunas de las animations para que no tengamos que ejecutar animations, si no son visibles en la página y digamos, en ese sentido, podemos ahorrar algo de potencia de cálculo. Una de las cosas que siempre debemos considerar al usar algunas de estas APIs web es el soporte del navegador. Aquí tenemos los principales proveedores que están apoyando algunas de estas APIs web. Y en este caso, todos ellos soportan esta. Así que es seguro usar esto en las versiones más recientes de cada navegador, lo cual es bastante genial. Bien, pasamos a nuestro próximo ejemplo. Pero antes de hacer eso, necesito hacer una pequeña configuración en mi portátil. Noten que mi portátil no está en batería, pero voy a poner eso por un minuto. Si mi portátil tiene un período de inactividad de un minuto, debería apagarse. Bien, pero vamos a ver eso. Bien, pueden haber notado al principio que no hablé mucho sobre mí. Pero ahora tengo un minuto para hablar. Así que es mi momento de brillar. Realmente me gusta viajar. Y cuando lo hago, Italia es uno de mis lugares favoritos en todo el mundo. La architecture, la gente, la comida, todo es tan increíble. Y no sé qué es esto, pero tanta pasión en un solo gesto. No sé. Es muy divertido para mí. Por supuesto, como dije, una de mis cosas favoritas sobre Italia es la comida. Y recientemente, una vez que llego a casa, me gusta preparar algunas recetas de comida italiana. Voy a la página web de cocina, y luego preparo la comida, cortando cebollas y lo que sea. Y después de un minuto de inactividad, no cronometré eso correctamente, ¿verdad? Pero esto sucede.
4. Previniendo el Bloqueo de Pantalla con la API de Screen Wake Lock
Short description:
Pero en realidad, lo que me sucede es que mi teléfono se apaga y luego tengo que volver a encenderlo con los dedos pegajosos y lo que sea. Así que mi dispositivo no se apagaría, aunque tenía algunas preferencias del sistema específicas de que necesitaba apagarse. Existe una API muy interesante llamada Screen Wake Lock API, que básicamente evita que nuestra pantalla se bloquee. Podría fallar en ciertas circunstancias, como si el nivel de batería es demasiado bajo. Ponemos esto en una referencia y no en el estado porque esta función devolverá un valor que se mantiene en la memoria. Los casos de uso incluyen leer un libro electrónico, presentar a la audiencia, seguir una receta de cocina, seguir la navegación del mapa y escanear un código QR o un código de barras. El soporte del navegador varía entre los proveedores.
O no. Bueno, en este caso, mi dispositivo no se apagó. Pero en realidad, lo que me sucede es que mi teléfono se apaga y luego tengo que volver a encenderlo con los dedos pegajosos y lo que sea. Bueno, entonces, ¿cómo logramos hacer esto? ¿Cómo evitamos este comportamiento? Así que mi dispositivo no se apagaría, aunque tenía algunas preferencias del sistema específicas de que necesitaba apagarse. Existe una API muy interesante llamada Screen Wake Lock API, que básicamente evita que nuestra pantalla se bloquee. Y solo puede funcionar si el documento es visible, si el usuario está observando la página en ese mismo segundo. Si hiciéramos esto en React, tendríamos un hook, digamos, use wake lock hook. Pero aquí, la situación es un poco más complicada que en el ejemplo anterior. Pasamos esa funcionalidad de alternancia, ¿está apagado o no? Y luego si hacemos eso, llamamos a request wake lock sentinel. Esa función va a llamar a un navegador, tenemos un objeto wake lock, y llamamos al método request y pasamos el parámetro de pantalla. Eso es una promesa. ¿Alguien puede decirme por qué creen que es una promesa? ¿Alguien? Sí, sí, por favor. Esa es una buena llamada. Pero en este caso, no, no tienes que hacer eso para pedir permiso para este, pero esa es una buena suposición. ¿Tienes tal vez alguna otra idea? Bueno, básicamente, podría fallar. Por eso es una promesa. Y podría fallar en ciertas circunstancias, como si tu nivel de batería es demasiado bajo, no podrías solicitar el sentinel. Y puede que te hayas dado cuenta de que ponemos esto en una referencia y no en el estado. ¿Por qué es eso? Porque esta función devolverá un valor que se mantiene en la memoria. Y necesitamos borrar ese valor exacto en la memoria. Si hacemos eso en el estado, lo perderíamos. Así que por eso tenemos que ponerlo en una ref. Y una vez que lo limpiamos, si apagamos el interruptor de nuevo, entonces tendríamos que borrar la referencia, y tendríamos que llamar al método release en esa referencia. Tenemos que hacer todos estos pasos. De lo contrario, no funcionará. Bueno, los casos de uso en este caso, digamos que estamos leyendo un libro electrónico, estamos presentando a la audiencia, estamos siguiendo una receta de cocina. Estamos siguiendo la navegación del mapa, y no queremos que nuestro mapa se apague o estamos escaneando un código QR o un código de barras. El soporte del navegador en este caso, bueno, no es como el anterior. Podemos ver que los proveedores de Chromium están apoyando esto, Firefox no tiene soporte para esto. Y este signo azul para Safari significa que está en fase experimental. Así que están llegando, pero todavía no están del todo allí. Así que eso es algo que
5. APIs de Sincronización en Segundo Plano y de Canal de Difusión
Short description:
Además, en nuestro último ejemplo, tenemos una aplicación llamada Suemirko.RS que se comunica con la API de la NASA para obtener una lista de planetas habitables. Nos encontramos con problemas de conectividad y utilizamos la API de sincronización en segundo plano para realizar tareas una vez que volvemos a estar en línea. Esta API nos permite registrar múltiples tareas en el trabajador de servicio y mejorar la experiencia del usuario fuera de línea. Otra API, la API de canal de difusión, permite la comunicación entre el trabajador de servicio y el componente.
siempre debemos estar conscientes de ello. Además, una de las cosas en este caso particular de la API es el soporte del dispositivo. No importa cuánto lo intenté, no pude hacer que esto funcionara en mi iPhone. Así que eso siempre es algo a considerar. Bueno. Y nuestro último ejemplo para hoy, digamos que tenemos una aplicación como esta. Llamada Suemirko.RS. Suemirko traducido aproximadamente al inglés significa astronauta, y es una aplicación un poco futurista, unos miles de años en el futuro, donde nos estamos comunicando con la API de la NASA para obtener la lista de todos los posibles planetas habitables, y queremos ir de vacaciones a algunos de estos planetas. Pero en el futuro, también podríamos tener algunos problemas de conectividad, problemas fuera de línea, porque ¿por qué no? Y una vez que desplazo este botón, eso debería desencadenar una solicitud a la API de la NASA y obtener la lista de los planetas. Pero como pueden ver, en la pestaña de red, no está pasando nada. ¿Verdad? ¿Alguien tiene idea de por qué es eso? ¿Qué esperarías normalmente si te desconectas y tratas de enviar una solicitud, qué esperarías en la pestaña de red? Sí, verías que la solicitud roja falló. Pero en este caso, no lo hizo. Pero lo interesante es que si vamos a la pestaña de la aplicación, y luego vamos a, hay una pestaña llamada sincronización en segundo plano. Vemos que algo está pasando allí. Hay algún tipo de evento registrado allí, y si nosotros volvemos a estar en línea, está bien, solo quiero mostrarles esto. Así que si vamos a esa página, podemos ver el cargador. Y si volvemos a estar en línea, podemos ver que hay un evento despachado, y hay una solicitud enviada en ese mismo punto. Después de que la solicitud ha terminado, obtuvimos una respuesta, obtenemos la sincronización completa en el evento. Y ahora podemos ver la lista de todos nuestros posibles planetas para las vacaciones, y podemos elegir el planeta al que queremos ir. Digamos, TOI561E, suena increíble. Siempre quise ir allí. Bueno. ¿Cómo logramos hacer esto? Hay una muy genial API llamada API de sincronización en segundo plano, que básicamente proporciona una forma para nosotros de poner algunas tareas en segundo plano para ser realizadas una vez que volvamos a estar en línea. Si hiciéramos esto en React de nuevo, tenemos nuestro componente, como esa página de inicio, y una vez que pasamos el botón, llamamos a la función para registrar la sincronización en segundo plano. En un objeto de navegador, es parte del trabajador de servicio en realidad. Tenemos que registrar primero la sincronización en segundo plano, y luego podemos registrar tareas específicas. La razón por la que hacemos esto es que podríamos querer tener múltiples tareas ejecutándose en segundo plano, ¿verdad? Y en nuestro trabajador de servicio, estamos escuchando el evento de sincronización, y si la etiqueta del evento es la misma que registramos en nuestro componente, entonces vamos a hacer algo. Los casos de uso, por supuesto, de mejorar la UX fuera de línea, o tal vez enviar un correo electrónico mientras estamos desconectados y se corta internet, y queremos que eso continúe. El soporte del navegador en este caso, de nuevo, no es tan bueno, pero esperemos un poco por ello. Si te preguntabas antes cómo nos comunicábamos entre nuestro trabajador de servicio y nuestro componente, hay una API muy genial llamada de difusión
6. Comunicación Bidireccional y Otras APIs Geniales
Short description:
Podemos comunicarnos bidireccionalmente entre el componente y el trabajador de servicio utilizando un canal específico y enviar mensajes. Esto nos permite enviar y recibir datos. Los casos de uso incluyen la detección de acciones del usuario y el cierre de sesión en múltiples pestañas. Hay otras APIs geniales para explorar, como la API de baliza para solicitudes unidireccionales, la API de discurso web para analizar gramática y discurso, y la API de visibilidad de página para controlar JavaScript y animaciones. El código estandarizado es crucial en un ecosistema en rápida evolución con nuevas bibliotecas que surgen con frecuencia.
API de canal, que básicamente nos permite la comunicación entre los mismos orígenes. Una vez que obtuvimos esa etiqueta de los trabajadores de servicio, una vez que obtuvimos ese evento, activamos la solicitud, obtuvimos los data, y enviamos esos data a través de un canal al componente, y funciona en ambos sentidos. Podemos comunicarnos desde un componente al trabajador de servicio, desde un trabajador de servicio al componente, y así sucesivamente. Lo demostraremos ahora. ¿Cómo lo hacemos? Nos conectamos al canal específico y luego llamamos a un mensaje de publicación. A través de este mensaje de publicación, podemos enviar cualquier información que nos gustaría a nuestro componente. En nuestro componente, nos suscribimos a ese mismo canal basado en un nombre, lo siento, y escuchamos el evento de mensaje. Una vez que sucede, obtendremos los data del trabajador de servicio. Los casos de uso en este caso, tal vez queremos detectar alguna acción del usuario, cerrar sesión en todas las pestañas si tenemos varias pestañas abiertas, y así sucesivamente. Soporte del navegador en este caso, estamos todos bien. Bueno, ya que tenemos un tiempo limitado hoy, desafortunadamente, tenemos que parar ahora con los ejemplos, pero espero que estén lo suficientemente interesados para investigar por su cuenta algunas de las otras APIs exóticas geniales, y si lo hacen, por favor avísenme. Me encantaría saberlo. Pero les daré algunos puntos extra. Hay una API de baliza si quieres enviar una solicitud pero no te importa la respuesta. El caso de uso para eso es algún tipo de análisis. Hay una API de discurso web para analizar la gramática y el discurso. Hay una API de visibilidad de página si quieres, digamos, detener algo de JavaScript, detener animations, o si estás viendo Udemy y digamos en modo de enfoque, no estás observando la página, quieres que el video se detenga, como si estuviera escuchando en segundo plano, estoy observando todo. No. Hay una API de red para observar las condiciones de la red. Hay una API de compartir web para compartir información entre dispositivos. API de búsqueda en segundo plano si estás descargando un archivo enorme y luego te quedas sin conexión, quieres continuar con esa descarga, y por supuesto una de las APIs más emocionantes y nuevas es probablemente Web Authen para el futuro sin contraseñas. Y algunas de las conclusiones. Hemos visto que algunas de estas APIs no tienen soporte de navegador. Algunas de ellas tienen soporte experimental. Algunas de ellas pueden tener dificultades con el soporte del dispositivo y hay un soporte limitado de TypeScript para algunas de estas. Pero, ¿por qué deberíamos usar estas APIs? ¿Por qué es este un buen enfoque? Porque es código estandarizado. Es código estandarizado. Es código estandarizado. No puedo enfatizar lo suficiente lo importante que es esto hoy en día, especialmente en nuestro ecosystem donde hay una nueva biblioteca que sale cada semana o cada día. Así que es realmente importante que tengamos esto como una única fuente de verdad y sepamos que
7. APIs y Responsabilidad Ambiental
Short description:
La mayoría de las APIs no son difíciles de aprender. Deberíamos priorizar el uso de las características incorporadas de JavaScript y las funcionalidades proporcionadas por el tiempo de ejecución. Si es necesario, podemos implementar código personalizado o encontrar bibliotecas. Este enfoque puede mejorar el rendimiento y reducir el tamaño del paquete de la aplicación. Con gran poder viene gran responsabilidad. Consideremos el bienestar de nuestro planeta. El desarrollo de JavaScript consume una cantidad significativa de electricidad. Debemos ser conscientes de nuestra huella de carbono. Gracias por asistir. Escanea el código QR para las diapositivas de referencia. Ahora, abordemos el soporte parcial de la API, específicamente WebOuton.
es estandarizado. Curva de aprendizaje suave. Por supuesto, la mayoría de estas APIs no son realmente tan difíciles de aprender. Y podríamos aumentar el performance con esto. ¿Qué queremos decir con esto? Por supuesto, no estoy diciendo que nunca debamos usar bibliotecas. No deberíamos reinventar la rueda si ya tenemos una biblioteca para esto. Pero estoy diciendo que si tenemos algo proporcionado por el JavaScript, por nuestros tiempos de ejecución, deberíamos optar por eso. Y luego si eso no nos funciona, entonces podríamos implementar nuestro código personalizado o intentar encontrar una biblioteca para ello y así sucesivamente. Como un efecto secundario total, esto podría tener un beneficio de performance. Porque el tamaño del paquete de nuestras aplicaciones sería menor. Y eso es súper importante porque el siguiente punto que estoy tratando de hacer, con gran poder viene gran responsabilidad. Así que sentí que es mi responsabilidad venir aquí y decir esto. Quería hablar un poco sobre nuestro planeta. Vale. Probablemente te estés preguntando qué tiene que ver nuestro planeta con JavaScript. Bueno, lo tiene. Escribimos nuestro código, lo empaquetamos, obtenemos ese paquete de JavaScript que enviamos a alguna plataforma cloud, ¿verdad? Esa plataforma cloud es básicamente como un gran centro de data con un montón de servidores que son computadoras conectadas a la electricidad. De hecho, usamos tanta electricidad que consume el 21% de la electricidad en todo el mundo. Lo cual es asombroso para mí. Afortunadamente para nosotros, hay un sitio muy interesante llamado calculadora de carbono de sitios web que puede proporcionarnos información sobre nuestra huella de carbono. Nuestro planeta es nuestro hogar. Solo tenemos un hogar. Y si no prestamos atención a él, si no cuidamos de nuestro hogar, entonces un día podría ser demasiado tarde. Muchas gracias por venir hoy. Este es el código QR, así que podrías escanearlo si quieres las diapositivas para referencia. Muchas gracias. Quizás algo personal primero. Cosas personales. ¿Qué APIs te faltan? ¿Faltan totalmente o faltan parcialmente? Vale. Voy a responder al soporte parcial
QnA
Manejo del Soporte de API y Rendimiento
Short description:
Por lo tanto, las características sin contraseña deberían ser compatibles con todos los navegadores. Algunas de las APIs no están en la especificación de GS, pero están estandarizadas por W3C y se comunican con todos los proveedores de navegadores. Agregar múltiples observadores de intersección puede llevar a fugas de memoria, pero pueden eliminarse utilizando un array de dependencia. Las pruebas para estos escenarios dependen del marco de pruebas utilizado. Cuando un navegador no admite una API, se puede implementar manualmente o a través de bibliotecas disponibles.
para algunas de las APIs. Eso es WebOuton. Por lo tanto, las características sin contraseña deberían ser compatibles en todos los navegadores. Pero para los que faltan, tendría que pensarlo. Pero puedes encontrarme más tarde en la llamada. Vale. Así que eso es algo para trasladar a la sala de discusión entonces. Así que otra pregunta que teníamos es que algunas de estas APIs no están en la especificación de GS. Entonces, ¿cómo podemos acordar que son standards o no? ¿Y cómo deberías tratar eso cuando estás desarrollando contra ellos? Así que está estandarizado por el estándar W3C. Y es algo que se comunica con todos los proveedores de navegadores. Y algunas de las APIs no tienen soporte en este momento, pero están de acuerdo en la API en el nivel de interfaz que van a proporcionar. Así que está estandarizado en ese sentido. ¿Y hay conflictos sobre eso? ¿Cómo deberías definir estos standards y cómo se resuelven? No conozco el proceso específico, cómo va, pero vi una de las charlas de las conferencias anteriores de Git Nation, y hay todo un proceso de cómo va. Y necesito volver a verlo, pero es un poco complicado, por supuesto, con cualquier estándar, pero es factible. Es posible. Vale. Bueno, si quieres ver la charla, está todo en el sitio web de Git Nation para volver a ver. Así que la siguiente pregunta que teníamos es, ¿qué tan costoso es performance-wise agregar múltiples observadores de intersección? ¿Alguna vez te meterás en problemas si sigues añadiéndolos? Bueno, sí, podrías tener. He visto algunos de esos casos de uso en la vida real donde hay una fuga de memoria y solo estás observando un elemento, pero sigues añadiendo observadores de intersección al mismo elemento. Así que eso es una fuga de memoria y deberíamos limpiar eso. Si te das cuenta en mi ejemplo, hay en ese hook, hay un array de dependencia para observar la referencia de un elemento. Así que si la referencia cambia, entonces es un nuevo observador de intersección y limpiamos el anterior. Pero si es el mismo elemento, siempre utilizará el mismo observador de intersección. De esa manera, nos defendemos contra las fugas de memoria.
¿Y qué tan fácil sería cubrir eso en testing? ¿Están todos soportados en React Testing Library o solo haces pruebas de extremo a extremo allí? En su mayoría mi experiencia es con pruebas de extremo a extremo. No sé exactamente cómo lo haría en Testing Library, pero supongo que lo simularía de alguna manera, proporcionaría algún tipo de función simulada para el observador de intersección. Sí, OK, genial. Creo que mientras estamos hablando de simular cosas, ¿cómo tratas si un navegador no admite la API? OK, esa es una muy buena pregunta. Así que lo primero que intento hacer es ir a la especificación y ver cómo funciona por debajo. Así que si es lo suficientemente fácil de implementar por tu cuenta, por ejemplo, con la API de ScreenWakelock específicamente, tuve ese problema en un proyecto que necesitaba resolverlo para todos los dispositivos. Y había algún tipo de biblioteca por ahí en GitHub, pero por debajo, estaba tratando de usar ScreenWakelock
Modificación del Código y Soporte del Navegador
Short description:
Intentaba modificar el código según nuestras necesidades y si eso no funciona, busco la biblioteca y su código fuente para ver cómo resuelve el problema. Aún no he explorado las implementaciones de los navegadores, pero podría ser un tema para futuras charlas. Edge tiene en su mayoría el mismo soporte que los navegadores basados en Chromium, alrededor del 95% del tiempo.
API, y si eso no funciona, había algún código adicional. Así que estaba intentando modificar ese código para nuestras necesidades personalizadas e intentando hacer que funcione. Si eso no funciona, entonces está bien intentar buscar la biblioteca específica que la está utilizando y resolviendo el problema. Pero de nuevo, esa biblioteca tuvo que hacerlo de alguna manera, ¿verdad? Así que luego voy a la biblioteca y miro a través del código fuente de la biblioteca e intento descubrir cómo la biblioteca está resolviendo ese problema en particular.
OK. Quiero decir, suena una buena manera, obviamente la fuente, cómo están haciendo las cosas. Cuando haces eso, ¿también miraste en la implementación del navegador de una biblioteca solo por diversión, entrando en la fuente de Firefox o Chromium?
No, no he visto eso hasta ahora. No he tenido la oportunidad de experimentar con ese tipo de ejemplo, pero después definitivamente lo haré. OK, tal vez esa sea la próxima charla que puedas darnos. No veo por qué no. Hablemos de algunas bibliotecas específicas o navegadores específicos. Lo siento, hice clic allí por error. ¿Cómo es el soporte en Edge? ¿Supongo que es el mismo que en Chromium? Sí, es en su mayoría el mismo que Chromium porque utilizan el motor Chromium. Así que una vez que mostré el logo de Chromium, básicamente me refería a los navegadores basados en Chromium. Así que en mi experiencia, el 95% del tiempo es el mismo soporte para Edge y Chrome. Eso es genial si pueden estandarizar en eso. API específica, ¿cuál es el estado de las notificaciones? No lo sé. No lo sé. Lo siento. OK, y tenemos otra pregunta, que todavía me interesa mucho. Así que tal vez puedas ampliar eso. ¿Cómo podemos hacer testing para eso de la mejor manera? ¿Tienes algún tip como última respuesta para nuestra audiencia si quieren abordar esto? ¿Cómo pueden asegurarse de que la user experience va a ser genial? No estoy seguro de que entienda la pregunta. Si usamos una API específica, ¿cómo podemos asegurarnos de que está mejorando la user experience? Sí. ¿Cómo estás testing? Como personalmente, en tus casos, ¿va a funcionar con todos los diferentes navegadores que tu cliente pueda traerte? Estás testing contra diferentes navegadores. OK, ahora lo entiendo. Gracias. Básicamente voy a la documentación de MDN y veo el soporte. Hay ese sitio web genial. ¿Puedo usarlo? Correcto. Así que escribo una API específica y luego me muestra toda la lista del soporte para cada navegador. Y luego simplemente pruebo las versiones. Puedo hacerlo manualmente o algunos de nuestros QA pueden hacerlo. Pero básicamente lo probamos en producción, si funciona para la versión específica, entonces, por supuesto, monitoreamos. Tenemos si estás usando Sentry o Datadog o algo así entonces estamos observando cómo nuestros usuarios están usando la aplicación desde qué navegador, desde qué versión. Y luego intentamos modificar las versiones y asegurarnos de que todo está funcionando para nuestros usuarios. Sí, gracias por la respuesta. Creo que nuestro tiempo ya se acabó. Así que den otra ronda de aplausos. Gracias. Gracias.
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
This Talk introduces the Epic Stack, a project starter and reference for modern web development. It emphasizes that the choice of tools is not as important as we think and that any tool can be fine. The Epic Stack aims to provide a limited set of services and common use cases, with a focus on adaptability and ease of swapping out tools. It incorporates technologies like Remix, React, Fly to I.O, Grafana, and Sentry. The Epic Web Dev offers free materials and workshops to gain a solid understanding of the Epic Stack.
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
The Talk discusses the concept of AHA programming, which emphasizes thoughtful abstractions. It presents a live-coded example of the life-cycle of an abstraction and demonstrates how to fix bugs and enhance abstractions. The importance of avoiding complex abstractions and the value of duplication over the wrong abstraction are highlighted. The Talk also provides insights on building the right abstractions and offers resources for further learning.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
Construir aplicaciones web modernas está lleno de complejidad. Y eso solo si te molestas en lidiar con los problemas ¿Cansado de conectar onSubmit a las API del backend y asegurarte de que tu caché del lado del cliente se mantenga actualizada? ¿No sería genial poder utilizar la naturaleza global de CSS en tu beneficio, en lugar de buscar herramientas o convenciones para evitarla o trabajar alrededor de ella? ¿Y qué te parecería tener diseños anidados con una gestión de datos inteligente y optimizada para el rendimiento que simplemente funciona™? Remix resuelve algunos de estos problemas y elimina completamente el resto. Ni siquiera tienes que pensar en la gestión de la caché del servidor o en los conflictos del espacio de nombres global de CSS. No es que Remix tenga APIs para evitar estos problemas, simplemente no existen cuando estás usando Remix. Ah, y no necesitas ese enorme y complejo cliente graphql cuando estás usando Remix. Ellos te tienen cubierto. ¿Listo para construir aplicaciones más rápidas de manera más rápida? Al final de esta masterclass, sabrás cómo:- Crear Rutas de Remix- Estilizar aplicaciones de Remix- Cargar datos en los cargadores de Remix- Mutar datos con formularios y acciones
Vue3 fue lanzado a mediados de 2020. Además de muchas mejoras y optimizaciones, la principal característica que trae Vue3 es la API de Composición, una nueva forma de escribir y reutilizar código reactivo. Aprendamos más sobre cómo usar la API de Composición de manera eficiente.
Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.
Tabla de contenidos: - Introducción a Vue3 - API de Composición - Bibliotecas principales - Ecosistema Vue3
Requisitos previos: IDE de elección (Inellij o VSC) instalado Nodejs + NPM
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
Top Content
Featured WorkshopFree
2 authors
Esta masterclass de SvelteKit explora la integración de servicios de terceros, como Storyblok, en un proyecto SvelteKit. Los participantes aprenderán cómo crear un proyecto SvelteKit, aprovechar los componentes de Svelte y conectarse a APIs externas. La masterclass cubre conceptos importantes incluyendo SSR, CSR, generación de sitios estáticos y despliegue de la aplicación usando adaptadores. Al final de la masterclass, los asistentes tendrán una sólida comprensión de la construcción de aplicaciones SvelteKit con integraciones de API y estarán preparados para el despliegue.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
Comments