Carga diferida de módulos JavaScript con ConditionerJS

 

 

 

  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX
  • SmashingConf Friburgo 2024

  • Índice
    1. Acondicionador y realce progresivo sentado en un árbol
    2. El problemático tercer acto
    3. Buscando almas
    4. Entonces, ¿qué pasa con esta cosa llamada acondicionador?
    5. Cambiar a acondicionador
    6. Pasar de funciones globales a módulos
    7. Pasar opciones de configuración a nuestros módulos
    8. Carga condicional de módulos según el contexto del usuario

    Vincular la funcionalidad de JavaScript al DOM puede ser una tarea repetitiva y tediosa. En este artículo, Rik Schennink explica cómo ConditionerJS puede ayudar a que los sitios web sean más flexibles y orientados al usuario. Paso a paso mejorará esta lógica y, finalmente, dará un salto de 1 kilobyte para reemplazarlo con acondicionador. Al combinar todos los pequeños cambios siguientes, puede acelerar el tiempo de carga de la página y adaptar mejor su funcionalidad a cada contexto diferente. Esto dará como resultado una experiencia de usuario mejorada y, como beneficio adicional, también mejorará nuestra experiencia de desarrollador.

     

    Vincular la funcionalidad de JavaScript al DOM puede ser una tarea repetitiva y tediosa. Agrega una clase a un elemento, busca todos los elementos en la página y adjunta la funcionalidad JavaScript correspondiente al elemento. ¡ El acondicionador está aquí no solo para quitarte este trabajo de las manos sino también para potenciarlo!

    En este artículo, veremos la lógica de inicialización de JavaScript que se utiliza a menudo para vincular componentes de la interfaz de usuario a una página web. Paso a paso mejoraremos esta lógica y, finalmente, daremos un salto de 1 Kilobyte para reemplazarlo con Acondicionador. Luego exploraremos algunos ejemplos prácticos y fragmentos de código y veremos cómo Conditioner puede ayudar a que nuestros sitios web sean más flexibles y orientados al usuario.

    Acondicionador y realce progresivo sentado en un árbol

    Antes de continuar, necesito dejar claro una cosa:

    Conditioner no es un marco para crear aplicaciones web .

    En cambio, está dirigido a sitios web. La distinción entre sitios web y aplicaciones web es útil para la continuación de esta historia. Permítanme explicar cómo veo la diferencia general entre los dos.

    Los sitios web se crean principalmente desde el punto de vista del contenido; están ahí para presentar contenido al usuario. El HTML está escrito para describir semánticamente el contenido. Se agrega CSS para presentar de manera agradable el contenido en múltiples ventanas gráficas. El último y tercer acto es colocar cuidadosamente JavaScript encima para agregar ese toque extra a la experiencia del usuario. Piense en un selector de fechas, navegación, animaciones de desplazamiento o carruseles (perdón por mi francés).

    Ejemplos de sitios web orientados al contenido son: Wikipedia, Smashing Magazine, el sitio web de su municipio local, periódicos y tiendas web. Las aplicaciones web se encuentran a menudo en el área de servicios públicos; piense en clientes de correo electrónico basados ​​en web y mapas en línea. Si bien también presentan contenido, el enfoque de las aplicaciones web suele estar más en interactuar con el contenido que en presentarlo. Hay una enorme zona gris entre los dos, pero este contraste nos ayudará a decidir cuándo el acondicionador podría ser eficaz y cuándo deberíamos mantenernos alejados.

    Como se indicó anteriormente, el acondicionador tiene que ver con los sitios web y está diseñado específicamente para abordar ese tercer acto:

    "Mejorar la capa de presentación con funcionalidad JavaScript para ofrecer una experiencia de usuario mejorada".

    El problemático tercer acto

    El tercer acto consiste en mejorar la experiencia del usuario con esa vibrante capa de JavaScript.

    A juzgar por la experiencia y lo que he visto en línea, la funcionalidad JavaScript a menudo se agrega a sitios web como este:

    1. Se agrega una clase a un elemento HTML.
    2. El querySelectorAllmétodo se utiliza para asignar a todos los elementos la clase.
    3. Un bucle for atraviesa el NodeListretorno en el paso 2.
    4. Se llama a una función de JavaScript para cada elemento de la lista.

    Pongamos rápidamente este flujo de trabajo en código agregando la funcionalidad de autocompletar a un campo de entrada. Crearemos un archivo llamado autocomplete.jsy lo agregaremos a la página usando una scriptetiqueta.

    function createAutocomplete(element) { // our autocomplete logic // ...}
    input type="text"/script src="autocomplete.js"/scriptscriptvar inputs = document.querySelectorAll('.autocomplete');for (var i = 0; i inputs.length; i++) { createAutocomplete(inputs[i]);}/script

    Ir a la demostración →

    Ese es nuestro punto de partida.

    Supongamos que ahora se nos dice que agreguemos otra funcionalidad a la página, digamos un selector de fecha, lo más probable es que su inicialización siga el mismo patrón. Ahora tenemos dos bucles for. Agregue otra funcionalidad y tendrá tres, y así sucesivamente. No es lo mejor.

     

    Si bien esto funciona y te mantiene alejado de la calle, crea una serie de problemas. Tendremos que agregar un bucle a nuestro script de inicialización para cada funcionalidad que agreguemos. Para cada bucle que agregamos, el script de inicialización se vincula cada vez más estrechamente a la estructura del documento de nuestro sitio web. A menudo, el script de inicialización se cargará en cada página. Lo que significa que todas las querySelectorAllllamadas para todas las diferentes funcionalidades se ejecutarán en todas y cada una de las páginas, ya sea que la funcionalidad esté definida en la página o no.

    Para mí, esta configuración nunca me pareció del todo correcta. Siempre comenzaba "bien", pero luego crecía lentamente hasta convertirse en una larga lista de bucles for repetitivos. Dependiendo del proyecto, puede contener alguna lógica condicional aquí y allá para determinar si algo se carga en una determinada ventana gráfica o no.

    if (window.innerWidth = 480) { // small viewport for-loops here}

    Con el tiempo, mi script de inicialización siempre se salía de control y se convertía en una pila gigante de código espagueti que no le desearía a nadie.

    Algo había que hacer.

    Buscando almas

    Soy un gran defensor de separar cuidadosamente las tres capas de desarrollo web: HTML, CSS y JavaScript. HTML no debería tener una relación rígida con JavaScript, por lo que no se deben utilizar onclickatributos en línea. Lo mismo ocurre con CSS, por lo que no hay styleatributos en línea. Agregar clases a elementos HTML y luego buscarlas en mis amados bucles for siguió muy bien esa filosofía.

    Sin embargo, tenía tantas ganas de deshacerme de esa pila de bucles de espagueti.

    Recuerdo haberme topado con un artículo sobre el uso de atributos de datos en lugar de clases y cómo se podrían usar para vincular la funcionalidad de JavaScript (no estoy seguro de que fuera este artículo, pero parece ser del período de tiempo correcto). No me gustó, lo entendí mal y mi pensamiento inicial fue que esto solo estaba encubriendo onclickesta mezcla de HTML y JavaScript, de ninguna manera iba a ser atraído al lado oscuro, no quiero hacer nada. con eso. Cerrar pestaña.

    Algunas semanas más tarde, volví a esto y descubrí que vincular la funcionalidad de JavaScript usando atributos de datos todavía estaba en línea con tener capas separadas para HTML y JavaScript. Al final resultó que, el autor del artículo me entregó una solución a mi creciente problema de inicialización.

    Actualizaremos rápidamente nuestro script para usar atributos de datos en lugar de clases.

    input type="text" data-module="autocomplete"script src="autocomplete.js"/scriptscriptvar inputs = document.querySelectorAll('[data-module=autocomplete]');for (var i = 0; i inputs.length; i++) { createAutocomplete(inputs[i]);}/script

    Ir a la demostración →

    ¡Hecho!

    Pero espera, esta es casi la misma configuración; solo hemos reemplazado .autocompletecon [data-module=autocomplete]. ¿Cómo es eso mejor? No lo es, tienes razón. Si agregamos una funcionalidad adicional a la página, todavía tenemos que duplicar nuestro bucle for: ¡explosión! Sin embargo, no estés triste, ya que este es el trampolín hacia nuestro bucle for asesino .

     

    Observe lo que sucede cuando hacemos un par de ajustes.

    input type="text" data-module="createAutocomplete"script src="autocomplete.js"/scriptscriptvar elements = document.querySelectorAll('[data-module]');for (var i = 0; i elements.length; i++) { var name = elements[i].getAttribute('data-module'); var factory = window[name]; factory(elements[i]);}/script

    Ir a la demostración →

    Ahora podemos cargar cualquier funcionalidad con un único bucle for.

    1. Encuentre todos los elementos en la página con un data-moduleatributo;
    2. Recorra la lista de nodos;
    3. Obtenga el namedel módulo del data-moduleatributo;
    4. Almacene una referencia a la función JavaScript en factory;
    5. Llame a la factoryfunción JavaScript y pase el elemento.

    Como ahora hemos hecho que el nombre del módulo sea dinámico, ya no tenemos que agregar ningún bucle de inicialización adicional a nuestro script. Esto es todo lo que necesitamos para vincular cualquier funcionalidad de JavaScript a un elemento HTML.

    Esta configuración básica también tiene otras ventajas:

    • El script de inicio ya no necesita saber qué carga; sólo necesita ser muy bueno en este pequeño truco.
    • Ahora existe una convención para vincular la funcionalidad al DOM; esto hace que sea muy fácil saber qué partes del HTML se mejorarán con JavaScript.
    • El script de inicio no busca módulos que no estén allí, es decir, no se desperdician búsquedas DOM.
    • El script de inicio está listo. No se necesitan más ajustes. Cuando agregamos funcionalidad a la página, ésta se encontrará automáticamente y simplemente funcionará.

    ¡Maravilloso!

    Entonces, ¿qué pasa con esta cosa llamada acondicionador?

    Finalmente tenemos nuestro único bucle, nuestro único bucle que rige a todos los demás bucles, nuestro rey de los bucles, nuestro hiperbucle. Ehm. Bueno. Simplemente tendremos que concluir que el nuestro es un bucle de alta calidad y es tan flexible que se puede reutilizar en cada proyecto (realmente no hay nada específico para el proyecto). Eso no lo hace inmediatamente digno de una biblioteca, sigue siendo un bucle bastante básico. Sin embargo, encontraremos que nuestro bucle requerirá algunos trucos adicionales para cubrir realmente todos nuestros casos de uso.

    Vamos a explorar.

    Con el bucle único, ahora estamos cargando nuestra funcionalidad automáticamente.

    1. Asignamos un data-moduleatributo a un elemento.
    2. Agregamos una scriptetiqueta a la página que hace referencia a nuestra funcionalidad.
    3. El bucle combina la funcionalidad adecuada con cada elemento.
    4. ¡Auge!

    Echemos un vistazo a lo que necesitamos agregar a nuestro bucle para hacerlo un poco más flexible y reutilizable. Porque tal como están las cosas ahora, aunque sea sorprendente, nos vamos a meter en problemas.

    • Sería útil si moviéramos las funciones globales a módulos aislados. Esto evita la contaminación de alcance global. Hace que nuestros módulos sean más portátiles para otros proyectos. Y ya no tendremos que agregar nuestras scriptetiquetas manualmente. Menos cosas que agregar a la página, menos cosas que mantener.
    • Al usar nuestros módulos portátiles en múltiples proyectos (y/o páginas), probablemente nos encontraremos con una situación en la que necesitemos pasar opciones de configuración a un módulo. Piense en claves API, etiquetas y velocidades de animación. Esto es un poco difícil en este momento ya que no podemos acceder al bucle for.
    • Con la diversidad cada vez mayor de dispositivos que existen, eventualmente nos encontraremos con una situación en la que solo queremos cargar un módulo en un contexto determinado. Por ejemplo, un menú que debe contraerse en ventanas gráficas pequeñas. No queremos agregar declaraciones if a nuestro bucle. Es hermoso como es, no agregaremos declaraciones if a nuestro bucle for. Nunca.

    Ahí es donde el acondicionador puede ayudar. Abarca todas las funciones anteriores. Además de eso, expone una API de complemento para que podamos configurar y expandir Conditioner para que se ajuste exactamente a la configuración de nuestro proyecto.

     

    Hagamos ese salto de 1 kilobyte y reemplacemos nuestro bucle de inicialización con Acondicionador.

    Cambiar a acondicionador

    Podemos obtener la biblioteca Conditioner desde el repositorio de GitHub , npm o desde unpkg . Durante el resto del artículo, asumiremos que el archivo de secuencia de comandos del acondicionador se agregó a la página.

    La forma más rápida es agregar la versión unpkg.

    script src="https://unpkg.com/conditioner-core/conditioner-core.js"/script

    Con Conditioner agregado a la página, tomemos un momento de silencio y digamos adiós a nuestro bucle for asesino.

    El comportamiento predeterminado de los acondicionadores es exactamente el mismo que el de nuestro bucle for ahora abandonado. Buscará elementos con el data-moduleatributo y los vinculará a funciones JavaScript de alcance global.

    Podemos iniciar este proceso llamando al hydratemétodo acondicionador.

    input type="text" data-module="createAutocomplete"/script src="autocomplete.js"/scriptscriptconditioner.hydrate(document.documentElement);/script

    Ir a la demostración →

    Tenga en cuenta que pasamos documentElemental método de hidrato. Esto le dice al acondicionador que busque en el subárbol del htmlelemento elementos con el data-moduleatributo.

    Básicamente hace esto:

    document.documentElement.querySelectorAll('[data-module]');

    ¡Bien, excelente! Estamos listos para llevarlo al siguiente nivel. Intentemos reemplazar nuestras funciones JavaScript de alcance global con módulos. Los módulos son piezas reutilizables de JavaScript que exponen ciertas funciones para usar en sus scripts. Blog sobre música Rock

    Pasar de funciones globales a módulos

    En este artículo, nuestros módulos seguirán el nuevo estándar de módulo ES , pero los ejemplos también funcionarán con módulos basados ​​en la definición de módulo universal o UMD .

    El primer paso es convertir la createAutocompletefunción en un módulo. Creemos un archivo llamado autocomplete.js. Agregaremos una única función a este archivo y lo convertiremos en la exportación predeterminada .

     

    export default function(element) { // autocomplete logic // ...}

    Es la misma que nuestra función original, solo que antepuesta export default.

    Para los otros fragmentos de código, cambiaremos de nuestras funcionesfunction clásicas a las de flecha .

    export default element = { // autocomplete logic // ...}

    Ahora podemos importar nuestro autocomplete.jsmódulo y usar la función exportada de esta manera:

    import('./autocomplete.js').then(module = { // the autocomplete function is located in module.default});

    Tenga en cuenta que esto sólo funciona en navegadores que admiten Dynamic import(). En el momento de escribir este artículo, serían Chrome 63 y Safari 11.

    Bien, ahora sabemos cómo crear e importar módulos, nuestro siguiente paso es decirle a Conditioner que haga lo mismo.

    Actualizamos el data-moduleatributo ./autocomplete.jspara que coincida con el nombre de archivo de nuestro módulo y la ruta relativa.

    Recuerde : el import()método requiere una ruta relativa al módulo actual. Si no anteponemos el autocomplete.jsnombre del archivo, ./el navegador no podrá encontrar el módulo.

    Conditioner sigue ocupado buscando funciones a nivel global. En su lugar, digámosle que cargue dinámicamente los módulos ES. Podemos hacer esto anulando la moduleImportacción.

    También necesitamos decirle dónde encontrar la función constructora ( module.default) en el módulo importado. Podemos apuntar al acondicionador en la dirección correcta anulando la moduleGetConstructoracción.

    input type="text" data-module="./autocomplete.js"/scriptconditioner.addPlugin({ // fetch module with dynamic import moduleImport: (name) = import(name), // get the module constructor moduleGetConstructor: (module) = module.default});conditioner.hydrate(document.documentElement);/script

    Ir a la demostración →

    ¡Hecho!

    El acondicionador ahora realizará una carga diferida automáticamente ./autocomplete.jsy, una vez recibido, llamará a la module.defaultfunción y pasará el elemento como parámetro.

    Definir nuestro autocompletado como ./autocomplete.jses muy detallado. Es difícil de leer y, al agregar varios módulos en la página, la escritura rápidamente se vuelve tediosa y propensa a errores.

    Esto se puede solucionar anulando la moduleSetNameacción. El acondicionador ve el data-modulevalor como aliasy solo utilizará el valor devuelto por moduleSetNamecomo nombre real del módulo. Agreguemos automáticamente la jsextensión y el prefijo de ruta relativa para hacernos la vida un poco más fácil.

    input type="text" data-module="autocomplete"/
    conditioner.addPlugin({ // converts module aliases to paths moduleSetName: (name) = `./${ name }.js`});

    Ir a la demostración →

    Ahora podemos configurarlo data-moduleen autocompletelugar de ./autocomplete.jsmucho mejor.

     

    ¡Eso es todo! ¡Hemos terminado! Hemos configurado el acondicionador para cargar módulos ES. Agregar módulos a una página ahora es tan fácil como crear un archivo de módulo y agregar un data-moduleatributo.

    La arquitectura del complemento hace que Conditioner sea súper flexible. Debido a esta flexibilidad, se puede modificar para usarlo con una amplia gama de cargadores y agrupadores de módulos. Hay proyectos de arranque disponibles para Webpack , Browserify y RequireJS .

    Tenga en cuenta que Conditioner no maneja el agrupamiento de módulos. Tendrá que configurar su paquete para encontrar el equilibrio adecuado entre servir un archivo empaquetado que contenga todos los módulos o un archivo separado para cada módulo. Por lo general, selecciono módulos pequeños y módulos principales de la interfaz de usuario (como la navegación) y los sirvo en un archivo empaquetado mientras cargo condicionalmente todos los scripts más abajo en la página.

    Muy bien, cargando el módulo - ¡compruébalo! Ahora es el momento de descubrir cómo pasar opciones de configuración a nuestros módulos. No podemos acceder a nuestro bucle; Además, realmente no queremos hacerlo, por lo que necesitamos descubrir cómo pasar parámetros a las funciones constructoras de nuestros módulos.

    Pasar opciones de configuración a nuestros módulos

    Quizás haya tergiversado un poco la verdad. Conditioner no tiene una solución lista para usar para pasar opciones a los módulos. Ahí lo dije. Para mantener el acondicionador lo más pequeño posible, decidí eliminarlo y ponerlo a disposición a través de la API del complemento. Exploraremos algunas otras opciones para pasar variables a módulos y luego usaremos la API del complemento para configurar una solución automática.

    La forma más fácil y al mismo tiempo más banal de crear opciones a las que puedan acceder nuestros módulos es definir opciones en el alcance de la ventana global.

    window.autocompleteSource = './api/query';
    export default (element) = { console.log(window.autocompleteSource); // will log './api/query' // autocomplete logic // ...}

    No hagas esto .

    Es mejor simplemente agregar atributos de datos adicionales.

    input type="text" data-module="autocomplete" data-source="./api/query"/

    Luego se puede acceder a estos atributos dentro de nuestro módulo accediendo al elemento datasetque devuelve uno DOMStringMapde todos los atributos de datos.

    export default (element) = { console.log(element.dataset.source); // will log './api/query' // autocomplete logic // ...}

    Esto podría resultar en un poco de repetición, ya que accederemos element.dataseten cada módulo. Si la repetición no es lo tuyo, sigue leyendo, lo solucionaremos enseguida.

    Podemos automatizar esto extrayendo datasete inyectándolo como parámetro de opciones al montar el módulo. Anulemos la moduleSetConstructorArgumentsacción.

    conditioner.addPlugin({ // the name of the module and the element it's being mounted to moduleSetConstructorArguments: (name, element) = ([ element, element.dataset ])});

    La moduleSetConstructorArgumentsacción devuelve una serie de parámetros que se pasarán automáticamente al constructor del módulo.

     

    export default (element, options) = { console.log(options.source); // will log './api/query' // autocomplete logic // ...}

    Sólo hemos eliminado la datasetllamada, es decir, siete caracteres. No es la mayor mejora, pero hemos abierto la puerta para llevar esto un poco más allá.

    Supongamos que tenemos varios módulos de autocompletar en la página y que todos y cada uno de ellos requieren la misma clave API. Sería útil si esa clave API se proporcionara automáticamente en lugar de tener que agregarla como un atributo de datos en cada elemento.

    Podemos mejorar la vida de nuestros desarrolladores agregando un objeto de configuración a nivel de página.

    const pageOptions = { // the module alias autocomplete: { key: 'abc123' // api key }}conditioner.addPlugin({ // the name of the module and the element it's being mounted to moduleSetConstructorArguments: (name, element) = ([ element, // merge the default page options with the options set on the element it self Object.assign({}, pageOptions[element.dataset.module], element.dataset ) ])});

    Ir a la demostración →

    Como nuestra pageOptionsvariable se ha definido, consttendrá un alcance de bloque, lo que significa que no contaminará el alcance global. Lindo.

    Usando Object.assignfusionamos un objeto vacío tanto con pageOptionseste módulo como con el datasetDOMStringMap que se encuentra en el elemento. Esto dará como resultado un objeto de opciones que contiene tanto la sourcepropiedad como la keypropiedad. Si uno de los elementos de autocompletar de la página tiene un data-keyatributo, anulará la clave predeterminada de pageOptions para ese elemento.

    const ourOptions = Object.assign( {}, { key: 'abc123' }, { source: './api/query' });console.log(ourOptions);// output: { key: 'abc123', source: './api/query' }

    Esa es una comodidad de primer nivel para los desarrolladores.

    Al haber agregado este pequeño complemento, podemos pasar opciones automáticamente a nuestros módulos. Esto hace que nuestros módulos sean más flexibles y, por lo tanto, reutilizables en múltiples proyectos. Aún podemos optar por no participar y usar dataseto abarcar globalmente nuestras variables de configuración (no, no lo hagas), lo que mejor se adapte a ti.

    Nuestro próximo desafío es la carga condicional de módulos. En realidad, es la razón por la que el acondicionador se llama acondicionador. ¡Bienvenidos al círculo interno!

    Carga condicional de módulos según el contexto del usuario

    En 2005, las computadoras de escritorio estaban de moda, todo el mundo tenía una y todo el mundo navegaba por la web con ella. Las resoluciones de pantalla iban de grande a más grande. Y aunque los usuarios podían reducir las ventanas de su navegador, nosotros miramos para otro lado y disfrutamos de la gloria de nuestros hermosos sitios de ancho fijo.

    He representado una impresión artística de la ventana gráfica de 2005:

    La ventana gráfica de 2005 en todo su esplendor, 1024 píxeles de ancho y 768 píxeles de alto. Maravilloso.

     

    Hoy, poco más de diez años después, hay más personas navegando por la web en dispositivos móviles que en computadoras de escritorio , lo que genera muchas ventanas gráficas diferentes.

    He aplicado este conocimiento a nuestra impresión artística a continuación.

    Más ventanas gráficas de las que puedas imaginar.

    ¡Santo cielo! Son muchas ventanas gráficas.

    Hoy en día, alguien puede visitar su sitio desde un pequeño dispositivo móvil conectado a un punto de acceso WiFi increíblemente rápido, mientras que otro usuario puede acceder a su sitio utilizando una computadora de escritorio con una conexión lenta. Sí, cambié las velocidades de conexión; la realidad es impredecible.

    Y pensar que nos preocupaba que los usuarios cambiaran el tamaño de la ventana de su navegador. ¡Ja!

    Tenga en cuenta que esos millones de ventanas gráficas no están escritas en piedra. Un usuario puede cargar un sitio web en orientación vertical y luego rotar el dispositivo (o cambiar el tamaño de la ventana del navegador), todo sin recargar la página. Nuestros sitios web deberían poder manejar esto y cargar o descargar funciones en consecuencia.

    Alguien que utilice un dispositivo pequeño no debería recibir el mismo paquete de JavaScript que alguien que utilice un dispositivo de escritorio. Eso no parece justo; Lo más probable es que resulte en una experiencia de usuario subóptima tanto en el pequeño dispositivo móvil como en el viejo dispositivo de escritorio.

    Con Conditioner implementado, configurémoslo como un controlador de acceso y hagamos que cargue módulos según el contexto actual del usuario. El contexto de usuario contiene información sobre el entorno en el que el usuario interactúa con su funcionalidad . Algunos ejemplos de variables de entorno que influyen en el contexto son el tamaño de la ventana gráfica, la hora del día, la ubicación y el nivel de la batería. El usuario también puede proporcionarle sugerencias contextuales, por ejemplo, una preferencia por el movimiento reducido . La forma en que se comporta un usuario en su plataforma también le dirá algo sobre el contexto en el que podría encontrarse: ¿es esta una visita recurrente?, ¿cuánto dura la sesión actual del usuario?

    Cuanto mejor seamos capaces de medir estas variables de entorno, mejor podremos mejorar nuestra interfaz para que sea apropiada para el contexto en el que se encuentra el usuario.

    Necesitaremos un atributo para describir los requisitos de contexto de nuestros módulos para que Conditioner pueda determinar el momento adecuado para que el módulo se cargue y descargue. Llamaremos a este atributo data-context. Es bastante sencillo.

    Dejemos atrás nuestro encantador módulo de autocompletar y centrémonos en un nuevo módulo. Nuestro nuevo módulo de alternancia de sección se utilizará para ocultar la navegación principal detrás de un botón de alternancia en ventanas gráficas pequeñas.

    Dado que debería ser posible descargar nuestra sección de alternancia, la función predeterminada devuelve otra función. El acondicionador llamará a esta función cuando descargue el módulo.

    export default (element) = { // sectionToggle logic // ... return () = { // sectionToggle unload logic // ... }}

    No necesitamos el comportamiento de alternancia en ventanas gráficas grandes, ya que tienen mucho espacio para nuestro menú (es un menú pequeño). Sólo queremos contraer nuestro menú en ventanas gráficas más estrechas que 30em(esto se traduce en 480px).

    Configuremos el HTML.

    nav h1 data-module="sectionToggle" data-context="@media (max-width:30em)" Navigation /h1 ul lia href="/home"home/a/li lia href="/about"about/a/li lia href="/contact"contact/a/li /ul/nav

    Ir a la demostración →

    El data-contextatributo hará que Conditioner cargue automáticamente un monitor de contexto que observe la consulta de medios (max-width:30em). Cuando el contexto del usuario coincida con esta consulta de medios, cargará el módulo; cuando no lo haga, o ya no lo haga, descargará el módulo.

    El monitoreo ocurre en base a eventos. Esto significa que una vez cargada la página, si el usuario cambia el tamaño de la ventana gráfica o rota el dispositivo, el contexto del usuario se vuelve a evaluar y el módulo se carga o descarga según las nuevas observaciones.

    Puede ver el monitoreo como detección de características. Cuando la detección de funciones se trata de una situación de activación/desactivación, el navegador admite W






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Carga diferida de módulos JavaScript con ConditionerJS

    Carga diferida de módulos JavaScript con ConditionerJS

    Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX SmashingConf Friburgo 2024 Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-carga-diferida-de-modulos-javascript-con-conditionerjs-950-0.jpg

    2024-05-20

     

    Carga diferida de módulos JavaScript con ConditionerJS
    Carga diferida de módulos JavaScript con ConditionerJS

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20