3 ms·
> It feels like how the DOM API should have been implemented. It doesn't look general enough to be a general-purpose API, for instance how would you look up an
by tveita 10y ago
> It feels like how the DOM API should have been implemented.
It doesn't look general enough to be a general-purpose API, for instance how would you look up an attribute on all <class> elements?
I tend to think of APIs like this as "application-grade". You could use it fine in the context of an application, where you know you will never have a DOM element named 'class' or any other edge case inputs, but you shouldn't build abstractions on top of it, because sooner or later a user will have an element named 'id', 'class' or 'attr', and your code will break.
The DOM API is verbose but explicit and consistent, you can write libraries like this without worrying much about leaking abstractions due to edge cases.
- shakna 10y agoNot sure if it's implemented in superdom but: for(i = 0; i < dom.class.<class>.length; i++) { console.log(dom.class.<class>[i].<attr>); } The DOM API isn't consistent, and that's what I hate about it. Compare: Creating an element: var newDiv = document.createElement("div"); body.appendChild(newDiv); Deleting an element: var element = document.getElementById("element-id"); element.parentNode.removeChild(element); Why does an element know how to remove its children but not itself? Superdom: delete dom.id.element-id Sure, there are some edge cases and roughness here, but its a library, not something curated and argued over by the various browsers until something roughly compliant appears.