2

I'm currently reading a book about building single page web applications. The application is currently in its very early stages, but the author incorporated two functions into the shell code, stateMap and jqueryMap. stateMap is for placing dynamic information shared across the module...I think I understand that. However, the jqueryMap is used to "cache jquery collections. This function should be in almost every shell and feature module we write. The use of the jqueryMap cache can greatly reduce the number of jQuery document traversals and improve performance."

Is anyone familiar with this technique? Can you explain this further?

uncoder
  • 1,818
  • 1
  • 17
  • 20
la1ch3
  • 497
  • 6
  • 16
  • 5
    Looks like the author is simply talking about caching results of (complex) jQuery selectors (`$('#foo > ul > li .bar small span')` etc.) for performance reasons. And while it is true that one usually tries to cache such stuff, especially when it is used multiple times, doing so for each and every little selection seems a bit over the top. Besides, that might turn out problematic if new elements are appended to the DOM – in that case one _must_ run such selectors again if one wants to get all elements including the new ones. – CBroe Jan 24 '15 at 01:54
  • 1
    @CBroe is right on the money . Have seen numerous times where people over cache selectors and don't realize when they use them the collection isn't a current representation of the DOM. Is a bug that can be tricky to find sometimes – charlietfl Jan 24 '15 at 02:32

1 Answers1

0

Even elementary DOM lookups in JavaScript, by element ID or class name, take considerable time by the browser, especially if the document is large.

Consider the following:

<div id="my-window"> ... </div>

A 'normal' jQuery way to locate the above DIV element by its ID would be as follows:

var $my_window = $('#my-window');  // expensive document traversal!

(Note that $('...') always represents a collection in jQuery, even if there is only a single element that matches the selector.)

If over the lifetime of your page you need to refer to that DIV multiple times in your script, such repeated lookups consume extra CPU cycles, causing your page to appear slow and ultimately degrading end user experience. What the author is suggesting is to perform such expensive lookups only once and store the results in a local cache of sorts, which is just a JavaScript object holding a bunch of references. Those references can then be reused as needed very quickly:

var jqueryMap = {}, setJqueryMap;

setJqueryMap = function () {
  jqueryMap = {
        $my_window: $('#my-window'),
        // store other references here 
  };
};

All you need to do is to call setJqueryMap function once when your module loads. Then you can refer to the desired element (or elements) by their 'cached' references:

setJqueryMap();

...

jqueryMap.$my_window  // do something with the element

That way the repeated traversals are avoided, making your script to perform much faster.

uncoder
  • 1,818
  • 1
  • 17
  • 20
  • You overstate how expensive element lookups are. Particularly lookups by id. Certainly, some lookups can be slow, depending on both the document and the selector. But, it's not expensive at all to do an element lookup by id. – gilly3 Dec 28 '16 at 01:12
  • Quite possibly, thanks. The point is, using cached references such as ``jqueryMap.$my_window`` is generally quicker than traversing the DOM with ``$('#my-window')`` over and over again. By how much - that's another story. But when it comes to repeated lookups, it all adds up. – uncoder Dec 28 '16 at 17:16