Proxies are cool. I use them in github.com/thebinarysearchtree/artwork which I haven't released. That libraries tag line is "you wanted less javascript and more html, so we delivered - artwork, the 100% javascript and css front-end framework". Anyway, I use proxies when I want a bunch of divs with classnames. You just do
const { container, heading } = divs;
and then container is assigned to an HTMLDivElement <div class="container"></div> and the same type of thing for heading because divs is a proxy for an object with getters that can figure out the name of the variable you are destructing into and create a new element with that class name. It saves a lot of code.
etc so my web components have less code than react components, and run at native hand-written speed. Proxies aren't actually slow despite what I had read via google. In fact, the proxy is a bit faster than the naive implementation because it caches the divs and cloneNodes them.
For the second way of creating elements (the span example), instead of creating a function for every html or svg tag, I use another proxy so you can do:
const { span, h3 } = html;
and it creates the span and h3 function dynamically. This saves me writing all the code for each tag and allows new tags to be used without me having to add them to the library.
Oh cool, that's very clever! Probably a little too clever for me, though :P I think the code is misleading, and you can't handle classes with hyphens in it (and if you do, that's even more misleading!). But it's a neat application of proxies!
For folks wondering, here's how it would work:
const htmlClasses = new Proxy({}, {
get: (target, prop, receiver) => document.querySelector('.' + prop)
});
// Get element with class pagetop
htmlClasses.pagetop;
const htmlNodes = new Proxy({}, {
get: (target, prop, receiver) => document.querySelectorAll(prop)
});
// Get all h3s
htmlNodes.h3;
Yes you can definitely argue that it is misleading, but given the alternative I was faced with (React) whose entire world is misleading and unknown, I decided I liked this option better. I write less code, I understand my code more, and it is native hand-written performance. You can also argue that these are all features of JavaScript, and so if you think that is misleading, getters are also misleading because the getter could be doing all kinds of things even though it looks like a standard property access. So it has to be put into perspective with Vue/React/etc, where your code doesn't even correspond to anything and the React engine underneath recreates the dom, diffs it, updates when it wants, etc, and the setState stuff relies on declaration order and all kinds of ridiculous garbage.
Anyway, I just think it is cool kind of for the same reason it is misleading :)
You can do a loop like:
for (let i = 0; i < 100; i++) {
const { cool } = divs;
cool.innerText = new Date();
document.body.append(cool);
}
and cool is actually a new div each time, even though you would think it was the same cool from divs (divs.cool). It also caches the div, so it is faster than even if you wrote the manual version with createElement.
I could get rid of it, because my other approach to element creation would is:
const cool = div({ className: 'cool' });
which isn't too bad, but when I have a lot of divs, it is just nicer to do:
> because divs is a proxy for an object with getters that can figure out the name of the variable you are destructing into and create a new element with that class name
A never ending well of new divs that have the class name of the variable name
They don't at all, at least in my implementation. I read that they affected performance greatly, but all of my real world and bench mark testing says they don't at all, and in fact allow me to cache partially created elements to improve performance.
For the second way of creating elements (the span example), instead of creating a function for every html or svg tag, I use another proxy so you can do:
and it creates the span and h3 function dynamically. This saves me writing all the code for each tag and allows new tags to be used without me having to add them to the library.