Browse: Home / , / Prototype's Array.any/all with jQuery

Prototype's Array.any/all with jQuery

By barneyb on May 8, 2008

I needed to convert a couple Array.any() and Array.all() calls (from Prototype) to jQuery syntax. Since jQuery doesn't extend the built-in objects with nice functionality like this, you have to fake it. Here's what I came up with. Old version ('images' is an array):

images.all(function(o){return o.status == "ready";})

and the new version:

jQuery.inArray(false,
  jQuery.map(images, function(o){return o.status == "ready";})
) < 0

Array.any()'s equivalent is the reverse:

jQuery.inArray(true,
  jQuery.map(images, function(o){return o.status == "ready";})
) >= 0

Might have to rip the Enumerable and Array extensions out of Prototype for standalone use as well.

Posted in ,

10 responses to “Prototype's Array.any/all with jQuery”

  1. Patrick McElhaney
    Patrick McElhaney
    May 9, 2008 at 7:23 am |

    I found a slightly simpler way to do what you want.

    All:

    jQuery.grep(images, function(o){return o.status == "ready";}).length == images.length

    Any:

    jQuery.grep(images, function(o){return o.status == "ready";}).length > 0

    Also, have you looked at the Collection plugin? I haven't used it myself, but it might have some of the stuff you're missing.

    If I were you I would try and avoid bringing stuff over directly from Prototype. It might stifle your JQuery indoctrination. :-)

  2. barneyb
    barneyb
    May 9, 2008 at 10:10 am |

    Patrick,

    Good call on grep(), that definitely makes the objective more clear.

    I'll have to take a deeper look at the Collection plugin, but I really don't see what's wrong with modifying the Array prototype. JavaScript (and ECMAScript) are specifically designed so that you can extend functionality that way – why not leverage it and make you code simpler?

    Maybe it's just the OO guy in me, but it annoys me that jQuery and CF share "separate state and behaviour" paradigm, and while CF does it for backwards compatibility, jQuery doesn't have an excuse. Why should I have to supply my "something" to some external procedure to add behaviour, why can't I just ask the "something" directly?

    CF: arrayLen(myArray); vs. myArray.length;

    jQuery: jQuery.grep(myArray, function(){}); vs. myArray.grep(function(){});

  3. Matt W.
    Matt W.
    May 9, 2008 at 3:25 pm |

    I believe jQuery does it for forward compatibility. See prototype using getElementsByClassName which is now native to Firefox 3.

  4. barneyb
    barneyb
    May 9, 2008 at 3:34 pm |

    Matt,

    document.getElementById("id") is requesting element from the document object. document.getElementsByClassName("name") is requesting elements from the document. Those are both the "right" way, in my view. CF doesn't have a direct corollary, but one could consider xmlSearch(document, "//*[@class='name'") to be very much the same thing (returning a list of elements from the document with the specified class name). Note the inversion of where the behaviour lives (on the object itself vs. in a global function).

    So getElementsByClassName follows the standard OO-like nature of JS.

  5. Matt W.
    Matt W.
    May 10, 2008 at 7:35 am |

    I see what you are saying, but my point was that because prototype added the getElementsByClassName method to the document object, it will overwrite the native implementation in Firefox 3. The native implementation should always be significantly faster. If jQuery were add to the grep method to the Array object directly, it would overwrite any future native grep method.

  6. barneyb
    barneyb
    May 10, 2008 at 8:40 am |

    Matt,

    I haven't actually checked, but I'd be utterly shocked if Prototype didn't do this:

    if (! document.getElementsByClassName) {
    document.getElementsByClassName = function(...) {...}
    }

    It's about making browsers consistent, not overriding built-in functionality (unless it's incorrect). So you use the native implementation wherever you can, supply a non-native one wherever it's needed, and have a consistent interface across browsers.

  7. Matt W.
    Matt W.
    May 10, 2008 at 10:00 am |

    They did do that, but here is an article that discussed the problems that happened when getElementsByClassName went native –

    http://ejohn.org/blog/getelementsbyclassname-pre-prototype-16/

  8. barneyb
    barneyb
    May 10, 2008 at 12:49 pm |

    Matt,

    Interesting. It's surprising that Prototype opted to return the $A()-ed result; I would not have expected that. But as the article points out, now that $$() is around, getElementsByClassName is basically unnecessary. Not going to help existing code, of course.

  9. JDD
    JDD
    May 12, 2008 at 5:46 am |

    Prototype's addition of document.getElementsByClassName() is deprecated and it is encouraged to use $$() instead.

    They returned the results $A'd to support chaining.
    Prototype created the document.getElementsByClassName function before it was even marked for addition in the effected browsers.

    - JDD

  10. Andy
    Andy
    October 2, 2013 at 8:08 am | 
    (function(window, $, undefined) {
  $.fn.all = function(callback) {
    var all = true;
    this.each(function() {
      if ( !callback.call(this) ) {
        all = false;
        return false;
      }
    });
    return all;
  };
  $.fn.any = function(callback) {
    var any = false;
    this.each(function() {
      if ( !!callback.call(this) ) {
        any = true;
        return false;
      }
    });
    return any;
  };
})(this, jQuery);