3 ms·
2 thoughts of the top of my head: 1 - is there no equivalent for .closest()? Traversal from relative paths is kind of a big deal for a jQuery-like tool 2 - wh
by lhorie 13y ago
2 thoughts of the top of my head:
1 - is there no equivalent for .closest()? Traversal from relative paths is kind of a big deal for a jQuery-like tool
2 - what is the type of `HTML.body.div`? HTMLDivElement or Array? If it depends on your markup, then that's a recipe for easy breakage
- emn13 13y agoYeah, this api is totally borked - they should always be returning a conceptual set, regardless of its cardinality.
- nadabu 13y agoIf you don't know, use each() and only() to act on the results. They're always available and don't care if it is an element or array of elements.
- lhorie 13y ago2 more thoughts :) 1 - you cannot be sure that return types will not change in the future (e.g. markup changes in maintenance phase), especially in large projects with lots of devs, hence my comment about brittleness. 2 - each() is verbose and encourages procedural style, which can cause redraw performance hits (i.e. someElements.readDOM().writeDOM() redraws much faster than someElements.each(function(el) {el.readDOM().writeDOM()}) since the browser's engine doesn't need to recalculate layout at every iteration re: closest() - I've seen people do things like $("li ul").closest("li").addClass("has-children") for things like dynamic expandable tree initialization. Granted, it's not a very common use case though.
- nadabu 13y ago1) i can reliably assume HTML.find('#foo') is a node, and HTML.find('.foo') must use each(). These things get even easier as web components and shadow DOM become widely available. I'm aiming at the future here, not the past. 2) elements.each('readDom').each('writeDom', 'value') 3) HTML.find('li ul').each('parentNode.classList.add', 'has-children')
- deleted 13y ago[deleted]