Inefficient jQuery usage warnings in PHPStorm IDE

Question

I recently upgraded my version of PHPStorm IDE and it now warns me about inefficient jQuery usage.

For example:

var property_single_location = $("#property [data-role='content'] .container"); 

Prompts this warning:

Checks that jQuery selectors are used in an efficient way. It suggests to split descendant selectors which are prefaced with ID selector and warns about duplicated selectors which could be cached.

So my question is:

Why is this inefficient and what is the efficient way to do the above selector?

I'd guess at:

var property_single_location = $("#property").find("[data-role='content']").find(".container"); 

Is this the right way?

Answer 1

I had the same question today and was able to find a solution thanks to Scott Kosman here.

Basically the answer is to select IDs individually and then use .find(...) for anything below. So taking your example:

$("#property [data-role='content'] .container"); 

Changing it to this makes PhpStorm happy and can evidently be more than twice as fast:

$("#property").find("[data-role='content'] .container"); 

Answer 2

I believe the difference between the two methods when using recent versions of jQuery and browsers is negligible. I constructed a test that shows that it is now actually 10% faster to do a combined selector rather than selection on id and then find for a very simple case:

http://jsperf.com/jquery-find-vs-insel

For selection of multiple children by class at any depth, the "find" does appear to be faster:

http://jsperf.com/jquery-find-vs-insel/7

There was some discussion about this on jQuery forums, but its 3 years old: https://forum.jquery.com/topic/which-jquery-selection-is-efficient As they point out here, if you are doing a lot of operations on same id selector, the greatest performance improvement is found by caching the top level element. On the other hand if you are doing just a few selections, there is going to be virtually no performance difference.

Therefor I believe that IntelliJ is overstating the importance of this code style.