DEV Community: Mánu Fosela

I’ve tried RTK and it saves a lot of tokens, but I think Squeezr is on another level.

Mánu Fosela — Sun, 05 Apr 2026 16:37:21 +0000

Sergio Ramos Vicente

Apr 5

I was burning through AI tokens without realizing it. Here's how I fixed it.

#ai #tooling #opensource #claude

Comments

3 min read

Over-Architecting in Web Design

Mánu Fosela — Thu, 10 Oct 2024 05:01:23 +0000

I recently read a post by @justinfagnani on X that says:

"Lit is not a framework. The browser is the framework."

This got me thinking about how we've been building for the web in recent years.

For quite some time now, if you know HTML, CSS, and JavaScript, you really don’t need a framework to build web applications. At most, you might use some libraries to simplify certain tasks, but even these are gradually being incorporated into the platform itself, like routing or state management.

Our focus, however, has shifted towards learning frameworks, and now meta-frameworks, which do make it easier to build web environments. They optimize pages, automatically generate necessary files like sitemaps.xml, optimize images, remove unused CSS, bundle, minify, and optimize JavaScript. They’re effective, yes. But they don't adhere to the standard.

Meta-frameworks like Astro let you use standards, but they don’t exactly make it easy. Instead, they streamline using other frameworks or their own components in a more user-friendly, non-standard format to "simplify" component creation. They also employ techniques to facilitate SEO, loading, and indexing—depending on how you’ve implemented them.

To me, this approach has two major issues:

Cognitive overload: Developers must learn to manage not only the framework itself but now also the meta-framework and its set of tools, which often adds unnecessary complexity to project architecture.
Detachment from the standard: Focusing on frameworks means we’re not investing time in understanding the latest developments in the web itself, which are substantial. CSS, for example, is making a huge leap forward with features like container queries. Meanwhile, JavaScript and HTML are also evolving, with HTML potentially introducing a new <select> element that will allow HTML and CSS within <option>, opening new and more flexible ways to create rich selectors.

In many frameworks, though, these innovations are implemented through their own components, so to developers, it can seem like these new features are framework inventions instead of standard advancements.

I remember a few years ago, when these meta-frameworks were just emerging, a developer excitedly told me, “They’ve invented SSR (Server-Side Rendering); now we can generate HTML on the server, creating static pages.” I looked at him in surprise. He insisted, thinking I was just as impressed with this “novelty” saying, “Isn’t it incredible? What a fantastic idea.” The irony was that SSR has been around since the early days of the web.

Today’s web developers, those studying web development and entering the field, often lack historical context. They don’t know how web development originally worked. They don’t understand the reasons we moved from server-side rendering to client-side rendering and started using frameworks. Somewhere along the line, when “Ajax” gained popularity, we lost our way—probably driven by the desire for standards to cover everything we needed, while big companies fought to impose their own criteria, tags, and languages in the browser (I still remember Microsoft’s infamous VisualBasicScript).

Frameworks aren’t the problem. Not at all. They added power and value to web development. They allowed us to create applications for everyone, spurring the rise of hundreds of thousands of web developers and bootcamps.

Frameworks and meta-frameworks aren’t the issue; they even helped democratize web development, enabling millions to create applications and fueling the bootcamp boom. But as the web platform matures and standards become more robust, framework creators have business incentives to retain and promote their tools. They’re not going to say, “Stop using my framework; you can do everything with standards now.” Plus, migrating applications built with these frameworks to the standard is nearly impossible, especially since, in my experience, most lack E2E or functional tests to ensure that migration maintains the original behavior.

So, why aren’t we investing in tools that help us leverage today’s standards?

There isn’t a meta-framework that “forces” you to use the standard, making it easier in the process.

We need solutions that help us organize our projects efficiently and assist with build and optimization tasks if we want to do SSR, CSR, SSG, ISR, Hydration, create MPAs or SPAs. But we should be fully aware of our needs and the pros and cons of each choice. These tools should optimize images, JavaScript, CSS, and generate only the necessary files. They should allow the use of libraries that stick to the standard and adequately cover the platform’s remaining gaps. They should optimize and support SEO, loading, and indexing, facilitate testing, and harness the platform’s power.

It’s time to reduce over-engineering and excessive architectural design in our web projects. Let’s keep learning, not just how to use a framework, but also how to appreciate and apply the incredible advancements in web standards.

No excuses.

Desarrollo Web y Web Components

Mánu Fosela — Tue, 29 Dec 2020 01:04:19 +0000

Disclaimer

Lo que vierto en este post es mi opinión. Mi punto de vista. Mi percepción. Desde mi experiencia y mis sesgos. Y sobre todo desde mi ignorancia en muchos campos.

Sobre mi y mis inicios como desarrollador

Llevo programando para la web desde 1997.
A parte de HTML, CSS y Javascript, he pasado por varios lenguajes: CGIs en C, ASP, JSP, PHP, Java, Perl y Ruby si no recuerdo mal. Algunos durante unos meses otros durante años.
He trabajado con bases de datos MSSQL, MySQL, Oracle, IBMDb2 y MongoDB.
Y he trabajado con servidores IIS, Apache, Tomcat y Nginx.
Desde siempre Windows (era un mal necesario) y Linux (era un suplicio a principios de siglo)

He visto cómo hemos pasado de que un desarrollador/equipo web fuera responsable de todo a la especialización más exquisita.
Aprendí a hacer testing, TDD, metodología XP y pair programing en 2007. Hacia 2008 con el boom de Javascript y Jquery, empecé a especializarme más en Javascript, aunque no fue hasta 2010 cuando pasé a ser “oficialmente” FrontEnd Developer, a pesar de que mis dotes de diseño dejan mucho que desear.
Y dejé de tocar la parte back y configuración de servidores. Dejé de subir a producción por FTP y empecé a usar control de versiones con CVS y Subversion.

Luego empezaron a aparecer librerías como Backbone y arrancó el boom de los frameworks del front, las llamadas AJAX y el desarrollo de APIs que alimentaban esos frontales “mágicos”

Por cierto, AJAX empecé a usarlo hacia 2007 cuando existía ¡¡desde 2002!! Y yo usando iframes ocultos, leyendo información y cargándola en la página principal, una “guarrada”... pero es que antes era otra epoca ;)

En 2015 me enganché a los web-components, con Polymer en su versión 0.8 y a la espera de que los ansiados estándares vieran su primera versión que no llegó hasta 3 años después.
Y aunque siempre he probado, y hecho alguna aplicación que otra, en todos los frameworks típicos, nunca me han entusiasmado en exceso.
Sí. Mola. Facilitan. Ahorran tiempo (una vez les coges el punto). Unifican los grandes desarrollos. La curva de aprendizaje puede venir hecha al incorporarte a un equipo. Y sobre todo hacen mucha “magia” que se puede traducir en desarrollo mas rápido y menos dolores de cabeza, pero ¿necesitaba usarlos?

Empiezo la polémica

Creo que en los proyectos grandes donde he trabajado, o he visto trabajar desde que ejerzo como manager, está plenamente justificado el uso de un framework, pero ¿Y en un blog? ¿Y en una web de contenidos? ¿Y en algunos juegos? En internet veo muchas webs que son contenidos y creo que no necesitan un framework para desarrollarlas.

¿Que se pueden usar frameworks? Correcto. ¿Que no penaliza? Bueno, depende. A nivel de lo que es una página web, solo hace falta hacer “botón derecho” (lo siento no uso Mac), “ver código fuente de la página” y ver en dicho código fuente “atrocidades” que ni DreamWeaver en sus mejores momentos…
Porque o bien no hay contenido, ya que se genera dinámicamente, y por tanto es contenido invisible a los crawlers de los buscadores, o bien lo que se escupe aparece “ofuscado”, cuando una web de contenido, justo lo que se tiene que leer perfectamente es el contenido, con sus tags HTML, usando la semántica de las etiquetas HTML (cuantos años luché al principio por una web Semántica)
O eso creí entender allá por 1997 cuando leí mi primer libro de HTML.

Y lo de que no es necesario usar un framework para generar contenido como un blog parece que se están dando cuenta la comunidad.
Por eso ¿Qué está pasando últimamente? Que alguien “descubre” el SSR (Server Side Rendering)
Y empiezan a aparecer frameworks sobre los frameworks para hacer lo que se hacía desde siempre, generar el contenido de la página desde en el servidor y que el navegador haga la petición y le envíe dicho contenido, eso sí, ahora usando toooooda la lógica del framework sobre otro framework. Volvemos a los inicios, pero complicándolo.
¿Por qué? Quizás porque lo no sabemos hacer de otra manera. Es lo que nos han enseñado.

Nos enseñan a usar algunas herramientas, pero no nos enseñan a pensar cuándo se deben usar dichas herramientas.
Como se suele decir: “Te enseñan a usar un martillo y todo son clavos”
¿Te enseñan el framework AcojoJS? Todo son aplicaciones con AcojoJS. Sin pararnos a pensar si es la solución idónea para nuestro problema. Funciona, ¿no?

Quizás porque no nos enseñan más.
Quizás porque no nos ponemos a pensar.
Quizás porque va todo tan deprisa que nos falta tiempo para aprender.

Porque aprendemos a usar un martillo, es decir a programar, y ¡ale! a clavar todo lo que pille, aunque sea un tornillo o un cristal.

Y es cierto. Aprendes lo suficiente para usar ese martillo con suficiente destreza. Pero nada más.
Aunque seamos conscientes de que la caja de herramientas es gigante y la cantidad de herramientas casi infinita, nos quedamos con nuestro martillo.

Pero sobre todo, creo que no se fomenta el buscar soluciones adecuadas a los problemas, si no a usar nuestra solución a cualquier problema.
Es decir, adaptamos problemas a nuestras soluciones, complicando más el problema.

Esto me pasó en uno de mis equipos, cuando nos plantearon un proyecto en el que teníamos vía libre para utilizar lo que quisiéramos. Greenfield Project lo llaman.
Pregunté:

¿Qué usamos? Todos al unísono:
Vue! Vue! Vue!

Mi pregunta era para implicar al equipo en el análisis del problema y buscar la solución adecuada, que facilitara el trabajo y la entrega a tiempo.
Pero mi sorpresa fue mayúscula cuando con un mínimo de información sobre el proyecto, todos pedían a Barrabás, en este caso Vuerrabás :P
Menos mal que en este caso no hice como Poncio Pilato, aunque si me lleve un Soponcio Parrato :P

Este es solo un claro ejemplo de a lo que nos conduce el mundo del desarrollo actual, del que me siento parte y responsable.

WebComponents

Y ya metidos en faena, quiero también reivindicar a los denostados, en algunos círculos, web-components estándar, incluidos en muchos frameworks, pero sin pertenecer a ninguno.

Y sobre todo quiero plantear mi disconformidad con el uso que se hace de ellos con el “Atomic Design”, es decir, crear componentes atómicos, que pueden usarse solos o como parte de un componente de orden superior, conocidos como “moléculas”. Y que estos últimos a la vez puedan conformar “organismos” de componentes…

No se. Me chirría. Siempre he visto los web-components como etiquetas HTML, como un <UL> o un <TABLE> o <DIV> solo que “haga más cosas”. Igual que crearon el tag <VIDEO>, que es realmente el concepto de un web-component aplicado: permite insertar vídeo en la web de manera sencilla, con su controlador del vídeo, la pantalla de vídeo, admitiendo diferentes formatos y fuentes…

Y veo bien web-components que aporten “cosas” que no hay. Un lector de QR. Un campo de formulario para votar con estrellas. Un reloj digital. Un calendario. Un menú. Hay mil ejemplos de necesidades.

¿Pero es un componente un ente formado por un <h1>, un <h2> y un <IMG> donde además ninguno de los 3 elementos tiene que aparecer siempre, pudiendo incluso llegar a ser solamente uno de ellos…?

El argumento suele ser “es que se repite”, “es que así es flexible”, “es que si no ¿cómo lo hacemos?”

Pues puede ser un componente web, cierto. Pero también puede no serlo. Si usas un framework quizás no te quede más remedio. O si no te han enseñado a cómo hacerlo sin que lo sea.

Bajo mi punto de vista, si usas web-components y estás generando páginas estáticas, aunque se alimente el contenido de una base de datos, al fin y al cabo, ese ente de <h1><h2><img> es simplemente una plantilla HTML.

Y puedo tener plantillas con combinaciones de esos 3 elementos, si realmente se llaman a todas las combinaciones de los mismos, porque si no, emplear tiempo en tenerlo “por si acaso” es tontería. Ese es otro de los grandes problemas del mundo del desarrollo que da para otro post.

Volviendo al problema planteado. Creo que siempre y cuando sean una simple presentación de tags HTML agrupados, sin ninguna funcionalidad, es una simple plantilla.
Si tuviera funcionalidad, entonces sí podría tener sentido que fuera un web-component. O si tuviera un diseño especial, que pueda chocar con el diseño global y necesite encapsular dicho diseño, también podría ser un web-component.

Es decir, creo que un web-component, la razón de crearlo es cuando:

Se puede reutilizar.
Tiene una presentación que no existe ya en un tag HTML
Tiene una funcionalidad que le da entidad y sentido.
Tiene una parte de su presentación/diseño abstraído del entorno donde se use.

Si no cumple alguno de esos puntos, debo analizar si realmente necesito diseñar un web-component o tengo alguna alternativa.

Y siguiendo esta premisa, por lo tanto para mi no tiene sentido un web-component no visual, que solo aporte funcionalidad, como a veces he visto los llamados “data managers”.

Para mi eso es un tag HTML que ya existe. Se llama <script>. Creo una “librería” con la funcionalidad que necesito. El API que he convenido. Y todo el que lo necesite lo usa. No veo la necesidad de hacerlo mediante un web-component.

Comunicación entre web-components.

Otra "unpopular opinion". Siempre se dice, yo de hecho lo he preguntado en alguna entrevista, ¿Cómo se comunican los componentes? Y quien se lo sabe, repite el mantra: “De padres a hijos mediante propiedades, de hijos a padres mediante eventos”

Bueno, desde el “Atomic Design” quizás ese mantra sí tiene sentido.
Pero si concibes los web-components cómo “tags” autónomos, que pueden convivir y estar anidados dentro de otros, pero independientes, la comunicación debería ser siempre mediante eventos. O mediante prospección.

O sea, aunque puede haber dependencias entre web-components, como la hay en un <table> con un <tr> y este con un <td> o un <ul> con un <li>. Pero realmente puedes usarlos por separado, aunque su funcionamiento no sea el esperado o no sea correcto.

Soy más partidario de un “Phenotypic Design” para los web-components. Es decir, diseñar los web-components basándonos en el conjunto de características visibles como resultado de la interacción entre su tipo y el medio.

Los tags HTML están clasificados por su tipo: Fundación, Formato, Formulario, Marco, Imagen, Audio, Enlace, Lista, Tabla, Estilo, Meta información y Programa.
¿Por qué no seguir esta clasificación y ampliarla para los web-components si es necesario?

Usando el concepto de “parientes” he visto siempre que ineludiblemente terminamos acoplando componentes padres, madres, hijos, sobrinas, abuelas y tíos todos entre sí, como buena familia. Pero ese no es el fin de los web-components, ya que solemos perder re-utilización fuera de la “familia”, creando verdaderas “mafias”.

Un web-component, por estar anidado dentro de otro no tiene porque crear una relación padre-hijo. Para mi tienen que crear una relación simbiótica. Y las hay de muchos tipos. Pueden ser un alga-hongo, creando un web-component de más valor. Árbol-ardilla, donde uno usa al otro para darle “cobijo”.
Creo que aporta una visión más amplia, menos limitante, donde es más fácil de mantener la individualidad, y por tanto la re-utilización de web-components en diferentes entornos, aplicaciones o webs.

Indexabilidad de los web-components

Otro tema que me ha preocupado siempre es que la encapsulación que hace el shadow DOM en los web-components que hace que su contenido no sea indexable y por tanto desaparece al darle a “ver código fuente de la página”, siendo invisible para los crawlers.

Pero esto creo que también es por un mal uso que le estamos dando a los web-components.

Si tengo por ejemplo un web-component de un menú de navegación, que al final puede ser un tag <nav> al que le hemos dado una funcionalidad especial en base a unos requisitos, incluso diferente en diferentes resoluciones pantalla, y al que le hemos dado un diseño concreto.
¿Por qué no utilizar el light-dom, es decir, el dom dentro del web-component, leer este en el ciclo de creación del mismo, y pintarlo conforme a los requisitos que necesitamos?
Estaríamos dando el contenido al crawler y encapsulando maquetación, diseño y funcionalidad. ¡Voila!

Porque otra aberración que veo bastante por ahí es pasar información a un web-component mediante un json ¡¡¡que insertamos como atributo!!!
¿Por qué no generar esa información en el light-dom con HTML semántico, indexable y accesible y luego “darle forma” en el web-component?

Es cierto que puede penalizar algo el tiempo de renderizado, pero no más si lo que tienes que leer es un json o una lista de elementos como atributo para pintarlos.
Y ademaś existen técnicas para poner un “loader” o añadir una animación de fade-in después del primer renderizado.

Por otro lado, si metemos el contenido del web-component en el light-dom, en el remoto caso de que no funcionara javascript, incluso podríamos asegurarnos de que la página tuviera contenido ya que el light-dom se renderiza, aunque probablemente se verá como “HTML feo” al no cargar el CSS de los componentes y no tener CSS para esos elementos HTML del light-dom.

Ejemplo de componente nav-list
En el repo de git se puede ver la evolución según versiones.

Mis conclusiones

No nos enseñan a buscar soluciones a los problemas, sino a usar las soluciones que conocemos ante cualquier problema.
Crear un web-component cuando:
- Se puede reutilizar.
- Tenga una presentación que no existe ya en un tag HTML
- Tenga una funcionalidad que le da entidad y sentido.
- Tenga necesidad de abstraer presentación/diseño del entorno donde se use.
Relación entre componentes simbiótica frente a la “familiar”
Comunicación entre componentes mediante eventos.
“Phenotypic Design” frente a “Atomic Design”
Utilizar el light-dom cuando sea posible, para insertar contenido al web-component y hacerlo indexable

Y si has leído hasta aquí ¡gracias! :)
Nos vemos por la comunidad.

Javascript Proxy: algunos usos prácticos

Mánu Fosela — Sun, 20 Sep 2020 01:10:05 +0000

Este post está basado en una mezcla de la traducción de los post del blog de Arbaz Siddiqui, y el blog de Eslam Hefnawy, javascrip.info
y del post en español de TodoJS y por su puesto de la documentación oficial en MDN

Introducción a Proxy

En términos de programación, proxy es cualquier entidad que actúa en nombre de alguna otra entidad. Un servidor proxy se encuentra entre un cliente y un servidor y actúa como cliente para el servidor y viceversa. El trabajo de cualquier proxy es interceptar las solicitudes / llamadas entrantes y reenviarlas en sentido ascendente. Esta intercepción permite que el proxy agregue lógica y cambie el comportamiento de las solicitudes entrantes y salientes.

El proxy Javascript es algo muy similar, se encuentra entre su objeto real y el código que intenta acceder a este objeto.
Nos permite hacer metaprogramación dinámica (metaprogramación: programas que escriben o manipulan otros programas).

Va a permitirnos interceptar las operaciones con objetos y sus propiedades de tal forma que podemos redefinir el comportamiento para cada una de estas acciones

De acuerdo con los documentos web de MDN:

El objeto Proxy se usa para definir comportamientos personalizados para operaciones fundamentales (por ejemplo, búsqueda de propiedades, asignación, enumeración, invocación de funciones, etc.).

Terminologías

Hay tres términos que necesitamos saber antes de poder implementar un proxy:

Objetivo (target)

Target es el objeto real que nuestro proxy interceptará. Este puede ser cualquier objeto de JavaScript.

Manejador (handler)

El manejador es un objeto donde viven todas las trampas.
Cada elemento de este objeto tiene como valor una función que implementa una trampa.

Trampas (trap)

Las trampas son métodos que interceptarán la llamada al destino cuando se llama a una propiedad o método. Hay muchas trampas definidas que se pueden implementar.
Los métodos que se pueden usar como trampas son:

Object methods:

getPrototypeOf()
setPrototypeOf()
isExtensible()
preventExtensions()
getOwnPropertyDescriptor()
ownKeys()

Property getters/setters:

has()
get()
set()
deleteProperty()

Function methods:

apply()
construct()

Ejemplo básico:

//movie is a target
const movie = {
    name: "Pulp Fiction",
    director: "Quentin Tarantino"
};

//this is a handler
const handler = {
    //get is a trap
    get: (target, prop) => {
        if (prop === 'director') {
            return 'God'
        }
        return target[prop]
    },

    set: function (target, prop, value) {
        if (prop === 'actor') {
            target[prop] = 'John Travolta'
        } else {
            target[prop] = value
        }
    }
};

const movieProxy = new Proxy(movie, handler);

console.log(movieProxy.director); //God

movieProxy.actor = "Tim Roth";
movieProxy.actress = "Uma Thurman";

console.log(movieProxy.actor); //John Travolta
console.log(movieProxy.actress); //Uma Thurman

El resultado de la ejecución del código anterior será:

God
John Travolta
Uma Thurman

En este ejemplo, nuestro objeto target era movie, implementamos un manejador con dos trampas: un get y un set.
Agregamos la lógica de que si estamos accediendo a la clave director, deberíamos devolver la cadena en God en lugar del valor real.
Del mismo modo, agregamos una trampa en el método set que interceptará todas las escrituras en el objeto de destino y cambiará el valor a John Travolta si la clave es actor.

Las posibilidades son infinitas

Casos de uso del mundo real

Aunque no es tan conocido como otras características de ES2015, Proxy tiene muchos usos.
Veremos escenarios del mundo real donde podemos usar proxies.

Validaciones

Como podemos interceptar las escrituras en un objeto, podemos hacer una validación del valor que estamos tratando de establecer en el objeto.

Por ejemplo:

const handler = {
    set: function (target, prop, value) {
        const houses = ['Stark', 'Lannister'];
        if (prop === 'house' && !(houses.includes(value))) {
            throw new Error(`House ${value} does not belong to allowed ${houses}`)
        }
        target[prop] = value
    }
};

const gotCharacter = new Proxy({}, handler);

gotCharacter.name = "Jamie";
gotCharacter.house = "Lannister";

console.log(gotCharacter);

gotCharacter.name = "Oberyn";
gotCharacter.house = "Martell";

La ejecución del código anterior dará como resultado lo siguiente:

{ name: 'Jamie', house: 'Lannister' }
Error: House Martell does not belong to allowed Stark,Lannister

En este ejemplo, restringimos que el valor permitido para la propiedad house solo pueda ser una de las casas permitidas. Incluso podemos usar este enfoque para crear objetos de solo lectura, todo lo que necesitamos hacer es lanzarlo dentro de la trampa set.

Efectos secundarios

Podemos usar proxies para crear efectos secundarios en una propiedad de lectura / escritura. La idea es activar alguna función si se accede o se escribe una propiedad en particular.

Por ejemplo:

const sendEmail = () => {
    console.log("sending email after task completion")
};

const handler = {
    set: function (target, prop, value) {
        if (prop === 'status' && value === 'complete') {
            sendEmail()
        }
        target[prop] = value
    }
};

const tasks = new Proxy({}, handler);
// ...otras tareas que al final llevan a poner un estado...
tasks.status = "complete";

La ejecución del código anterior dará como resultado el siguiente resultado:

sending email after task completion

Aquí estamos interceptando la escritura de la propiedad 'status' y si status está completa, estamos ejecutando una función de efectos secundarios.

Almacenamiento en caché

Como podemos interceptar el acceso a las propiedades del objeto, podemos construir en cachés de memoria para devolver solo valores de un objeto si no ha caducado.

Por ejemplo :

const cacheTarget = (target, ttl = 60) => {
    const CREATED_AT = Date.now();
    const isExpired = () => (Date.now() - CREATED_AT) > (ttl * 1000);
    const handler = {
        get: (target, prop) => isExpired() ? undefined : target[prop]
    };
    return new Proxy(target, handler)
};

const cache = cacheTarget({age: 25}, 5);

console.log(cache.age);

setTimeout(() => {
    console.log(cache.age)
}, 4 * 1000);
setTimeout(() => {
    console.log(cache.age)
}, 6 * 1000);

La ejecución del código anterior dará como resultado el siguiente resultado:

25
25 // a los 4 segundos
undefined // a los 6 segundos

Aquí hemos creado una función que devuelve un Proxy. El manejador de ese Proxy primero comprueba si el objeto ha caducado o no. Podemos ampliar esta funcionalidad para tener TTL basados en cada clave.
Otra aproximación puede ser usar ese TTL para pedir a una API (fetch) los datos una vez caducado.

Observar cambios en objetos

Como podemos interceptar el acceso a las propiedades del objeto, podemos crear nuevos elementos en DOM y renderizarlos cuando detectamos que una propiedad cambia o si se añade una nueva.

// NOTA IMPORTANTE!! 
// En el DOM tenemos un div con id=“salida”
//
function render(prop) {
  const salida = document.getElementById("salida");
  if (!document.getElementById(prop)) {
    const div = document.createElement("div");
    div.id = prop;
    salida.appendChild(div);
  }
  document.getElementById(prop).innerText = observables[prop];
}

handlerObservables = {
  set: function (observable, prop, value) {
    Reflect.set(observable, prop, value);
    render(prop);
    return true;
  },
  deleteProperty(observable, prop) {
    const elem = document.getElementById(prop);
    elem.parentNode.removeChild(elem);
    Reflect.deleteProperty(observable, prop);
    return true;
  }
};

const object = {};

const observables = new Proxy(object, handlerObservables);

observables["prueba"] = "valor";
// observables['otro'] = 'otro valor';
// delete observables['prueba'];

Si añadimos al objeto observables nuevos elementos, estos se irán añadiendo en el DOM dentro de la capa con id salida.
Si eliminamos del objeto elementos, estos se irán eliminando también del DOM.

Data binding

El enlace de datos suele ser difícil de lograr debido a su complejidad. El uso de proxies para lograr un enlace de datos bidireccional se puede ver en algunas “librerías” MVC en JavaScript, donde un objeto se modifica cuando el DOM sufre un cambio.

En pocas palabras, el binding de datos es una técnica que une varias fuentes de datos para sincronizarlas.

Supongamos que hay un con el id de username.

<input type = "text" id = "username" />

Digamos que se desea mantener el valor de esta entrada sincronizado con una propiedad de un objeto.

const inputState = {  id : 'nombre de usuario' , valor : '' }

Es bastante fácil modificar el valor de inputState cuando el valor del input cambia escuchando el evento ‘change’ del input y luego actualizando el valor de inputState. Sin embargo, lo contrario, actualizar el input cuando el valor de inputState se modifica, es más complicado a priori.

Un Proxy puede ayudar a lograrlo.

const input = document.querySelector('#username');
const handler = {
    set: function(target, key, value) {
        if (target.id && key === 'username') {
            Reflect.set(target, value);
            document.querySelector(`#${target.id}`)
            .value = value;
            return true;
        }
        return false;
    }
}

const proxy = new Proxy(inputState, handler)
proxy.value = 'John Doe'
console.log(proxy.value, input.value) 
// 'John Doe' will be printed for both

De esta manera, cuando haya cambio en inputState, el input reflejará el cambio que se ha realizado.
Combinado con escuchar el evento ‘change’, esto producirá doble data binding simple de input e inputState.

Si bien este es un caso de uso válido, generalmente no se recomienda por performance.

Convertir un array de objetos en agrupable

Este quizás sea el ejemplo más complejo, donde se anidan dos Proxy para poder agrupar por el campo que indiquemos.

Partimos del siguiente json con datos sobre características de procesadores:

const procesadores2020 = [
 {
   "procesador": "Athlon 200GE",
   "nucleos": "2",
   "hilos": "4",
   "frecuencia-min": "3.2GHz",
   "frecuencia-max": "3.2GHz",
   "precio": "66.18 €"
 },
 {
   "procesador": "Core i3-9100F",
   "nucleos": "4",
   "hilos": "4",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "67.99 €"
 },
 {
   "procesador": "Ryzen 3 3100",
   "nucleos": "4",
   "hilos": "8",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "3.9 Ghz",
   "precio": "105.58 €"
 },
 {
   "procesador": "Ryzen 5 2600X",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "136.35 €"
 },
 {
   "procesador": "Core i5-10400F",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "2.9 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "149.89 €"
 },
 {
   "procesador": "Ryzen 5 3600",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "200.80 €"
 },
 {
   "procesador": "Ryzen 7 2700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "207.59 €"
 },
 {
   "procesador": "Core i7-10700K",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "5.1 Ghz",
   "precio": "384.90 €"
 },
 {
   "procesador": "Ryzen 7 3700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.4 Ghz",
   "precio": "309.95 €"
 },
 {
   "procesador": "Core i9-10850K",
   "nucleos": "10",
   "hilos": "20",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "5.2 Ghz",
   "precio": "486.00 €"
 },
 {
   "procesador": "Ryzen 9 3900X",
   "nucleos": "12",
   "hilos": "24",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "4.6 Ghz",
   "precio": "443.90 €"
 },
 {
   "procesador": "Ryzen 9 3950X",
   "nucleos": "16",
   "hilos": "32",
   "frecuencia-min": "3.5 Ghz",
   "frecuencia-max": "4.7 Ghz",
   "precio": "758.87 €"
 },
 {
   "procesador": "Ryzen Threadripper 3970X",
   "nucleos": "32",
   "hilos": "64",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.5 Ghz",
   "precio": "2099.00 €"
 }
];

Si queremos poder agrupar por los campos de los objetos del array este sería el código.

const groupable = (collection) => {
 // Comprueba que la colección sea un array
 if (!(collection instanceof Array)) {
   throw new TypeError("The input collection is not an Array");
 }

 let grouped = {};
 Object.defineProperty(collection, "groupBy", {
   configurable: true,
   enumerable: false,
   writable: false,
   value: {}
 });

 return new Proxy(collection, {
   get(target, property, receiver) {
     if (property === "groupBy") {
       return new Proxy(target[property], {
         get(target, property, receiver) {
           // si la propiedad a agrupar no existe devolver []
           if (!collection[0].hasOwnProperty(property)) {
             console.log('no encontrado')
             return [];
           }
           // caso contrario, agrupar por la propiedad
           const output = {};
           collection.groupBy[property] = {};
           grouped[property] = {};
           collection.reduce(function(acc, cur) {
             if (!Array.isArray(acc[cur[property]])) {
               acc[cur[property]] = [];
             }
             acc[cur[property]].push(cur);
             return acc;
           }, output);
           grouped[property] = {...output};
           return grouped;
         }
       });
     }
     return Reflect.get(target, property, receiver);
   }
 });
};

const datasource = groupable(procesadores2020);
console.log(datasource.groupBy['hilos']);
console.log(datasource.groupBy['frecuencia-max']);

Cuando declaramos el array como “groupable” llamando a la función con el mismo nombre y pasandole el array, lo primero que hace es crear una nueva propiedad llamada “groupBy”, convirtiendo el array y devuelve un Proxy que intercepta el get del array.
Podemos decir que hemos ampliado los métodos del array.

De esta manera si llamamos a cualquier propiedad 0, 1, 2… devolverá el objeto correspondiente a esa posición.
Si llamamos a groupBy nos devuelve otro Proxy que tiene otra trampa en get de manera que a partir del campo que recibe, recorre el array y los agrupa por el campo pasado y devuelve el array agrupado.

Esta manera es la manera de añadir funcionalidad a objetos de javascript sin tener que tocar su 'prototipo'.

Por ejemplo, en String tenemos el método toLowercase() y toUppercase() pero no tenemos el método capitalize(). Si queremos añadir a String el método capitalize podemos hacerlo modificando la cadena protypica del tipo primitivo string:

   String.prototype.capitalize = function() { 
     const str = [...this]; 
     str[0] = str[0].toUpperCase(); 
     return str.join(''); 
   }

   console.log('buenos días'.capitalize()); // Buenos días

De esta manera, todos los String que se creen a partir de esa declaración tendrán un nuevo método 'capitalize' que convierte la primera letra en mayúscula.

Si esto lo hacemos mediante Proxy, al no ser String un objeto sino un tipo primitivo, tenemos que convertir el String en Object, con lo que perdemos los métodos de String:

const addCapitalize = function(value) {
  const arrStr = [...value];
  arrStr.capitalize = function() {
    arrStr[0] = arrStr[0].toUpperCase();
    return arrStr.join(''); 
  }
  return new Proxy(arrStr, {
    get(target, property, receiver) {
      let value = new String(arrStr.join(''));
      if (property === 'capitalize') {
        value = target[property];
      }
      return value;
    }
  });
}

const saludo = addCapitalize('buenos días');
console.log(saludo.capitalize());
console.log(saludo.toUpperCase()); // ERROR: perdemos el resto de métodos de String...

Con lo que está no parece ser la manera de ampliar métodos en tipos primitivos.

Inconvenientes de los Proxies

Si bien los proxies son bastante “mágicos”, hay algunos inconvenientes con ellos por que debemos tener cuidado.

El rendimiento puede tener un impacto drástico cuando se usan muchos proxies y, por lo tanto, debe evitarse al escribir un código donde el rendimiento sea crítico.
Dado un objeto, no hay forma de saber si se trata de un objeto Proxy u objetivo.
Por último, los servidores Proxy no necesariamente conducen a un código muy limpio y fácil de entender.

Conclusión

Los proxies son increíblemente poderosos y se pueden usar y abusar para una amplia gama de cosas.