4 ms·

I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?

• somecallitblues 10y ago
  See my reply child post. But anything from tying a quick event of any kind to an element and posting a form using Ajax and consuming the response, doing quick show and hide. And the ease of implemting a million different plugins for all kinds of things, from morals to slides, in this jQuery is still a champ.
• adamlett 10y ago
  JQuery still smoothes over browser inconsistencies. For instance, I was recently bit by this: https://connect.microsoft.com/IE/feedback/details/878564/element-classlist-toggle-does-not-support-second-parameter https://connect.microsoft.com/IE/feedback/details/878564/ele...
• mercer 10y ago
  I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions. With jQuery I'd often do $(<root-element>).on('click', <target element>, callback); crucially, because events bubble up, even a click on a child element of <target element> will register as a click on the target element. in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on. Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'. event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check. Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?
  • dham 10y ago
    This is what I use in my vanilla js projects for event delegation. function delegate(el, evt, sel, handler) { el.addEventListener(evt, function (event) { let t = event.target while (t && t !== this) { if (t.matches(sel)) { handler.call(t, event) } t = t.parentNode } }) } delegate(document, 'click', '[data-behavior="open"]', function (event) { event.preventDefault() }) You'll need a matches polyfill if supporting browsers that don't support el.matches
  • losvedir 10y ago
    > in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on. Unless I misunderstand, I think you might be looking for "event.currentTarget". event.target is the element that was clicked on, event.currentTarget is the element that has the event listener attached.
    • mercer 10y ago
      Yeah, but that would then either be 'document' or the 'root' of my widget/component, no? Not the 'item' which is somewhere in between the root and the target. $().on() is very convenient in that way.
      • losvedir 10y ago
        I see, I missed the "<target element>" part of the call. Well, why not just attach the event listener to that, then? `querySelector` / `querySelectorAll` can be called on any old element, not just document. <root-element> .querySelector(<target element>) .addEventListener('click', function(event){ // event.currentTarget refers to // <target element> no matter which of its // children were clicked }); Admittedly, this doesn't work as well for multiple target elements. I use a forEach polyfill which could loop through them, but that could create a lot of event listeners when possibly you'd only need one higher up. Depends how many there are, I suppose.