Question

90

Do I really need to check if an element exists with jQuery?

rated 0 times [ 97] [ 7] / answers: 1 / hits: 16039 / 8 Years ago, wed, august 3, 2016, 12:00:00

I recently had a question about how to correctly check if an element exists with jQuery. I found the answer from here:

https://learn.jquery.com/using-jquery-core/faq/how-do-i-test-whether-an-element-exists/

In summary:

if ( $( #myDiv ).length ) {

    // Do something

}

One guy I work with says the correct way to check should be:

if ($( #myDiv ) && $( #myDiv ).length ) {

    // Do something

}

Does it matter? I mean from a performance or latency wise, do they perform the same?

Also:

$( #myDiv ).show();

$( #myDiv ).hide();

$( #myDiv ).val('');

In these type of jQuery functions, it seems no if check is needed because they won't raise an error if #myDiv does not exist, correct?

For what it's worth, I am using jQuery 1.6.4.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

jase

Add To Favorites

Follow

Total Points: 442

Total Questions: 107

Total Answers: 94

Location: Sao Tome and Principe

Member since Wed, Dec 29, 2021

2 Years ago

answered 8 Years ago sandra · Accepted Answer

One guy I work with says the correct way to check should be:
if ($( "#myDiv" ) && $( "#myDiv" ).length ) {

    //do something

}

He's wrong, at least in terms of the $( "#myDiv" ) && part. jQuery's $(selector) always returns an object, which by definition is truthy. So that part is pointless, and re-querying the DOM for no reason.

I mean from a performance or latency wise, do they perform the same?

Re-querying the DOM for no reason is a waste, but most of the time it doesn't matter in any observable way, and especially not for ID selectors like $("#myDiv") which are optimized by jQuery into calls to getElementById (which is blazingly-fast). So on the one hand, yes, it's wasteful extra work. On the other hand, browsers are so fast these days that you probably have bigger fish to fry. But it's probably extra pointless code, which is the larger issue.

To the general point: jQuery is set-based. This means that operations on sets with no elements in them are no-ops. E.g.:

$(".foo").addClass("bar");

...is a no-op (not an error) if no .foo elements are in the DOM.

So check for length if and when you care whether you matched elements. If you don't care and just want to perform operations on them if they're there, just go ahead and do the operation (with one important caveat¹).

So basically, there are three scenarios:

You know the elements will be there, so the check is pointless
=> no check

You don't know the elements will be there, but you don't care and just want to operate on them if they're there
=> no check

You care whether the elements are there for some other reason
=> do the check

¹ Here's the important caveat: If you're calling a jQuery function that returns something other than a jQuery object (for instance, val() or offset() or position(), etc.), when you call it on an empty set, it will typically return undefined (the exception is text(), which will return "" [text() is not like the others in several ways; this is one of them]). So writing code that naively assumes those things will return what you're expecting, even when the set is empty, will bite you.

So for example:

if ($(".foo").offset().top > 20)

...will throw an error if there are no .foo elements, because offset() will return undefined, not an object.

But this is fine:

$(".foo").closest(".bar").toggleClass("baz"):

...because even if there are no .foo, closest() will return another empty jQuery set, and calling toggleClass() on it is a no-op.

So when dealing with an accessor that doesn't return a jQuery object, if you don't know for sure you're dealing with a set containing at least one element, you need more defensiveness, e.g.:

var offset = $(".foo").offset();

if (offset && offset.top > 20)

Again, most accessors (that don't return jQuery objects) do this, including val(), offset(), position(), css(), ...