Say I have an element on the page:
<div data-name='foo'>
What's the best way to get the attribute value? Is there anything more DRY than $('[data-name]').attr('data-name') or $('[data-name]').data('name')?
I don't know how do you define "DRY"...
if (x < 0) x = 1 isn't "DRY" because you wrote x twice?
Anyway with the current DOM structure, no there is not. The selector is inefficient which is more important!
You can give the element an id, which make the code faster.
<div id='foo' data-name='foo'> </div>
...
$('#foo').data('name'); // That's more like it.
I wouldn't know what this has to do with 'Don't Repeat Yourself', but if you don't have a cached reference to this node you would have to use that, rather verbose, call.
It might be a good idea to have at least an id for the nodes. The DOM query for that is lighting fast in comparison to that attribute-selector. But afterall, it's still the fastest technique to store a reference in a variable, like
var myNode = $('[data-name]');
and then use that variable throughout your whole application
myNode.data( 'name' );
You could have a plugin that did something like this. I'm not sure the additional overhead is worth it, though.
function getData(varName) {
var selector = '[data-' + varName + ']';
return $(selector).data(varName);
}
(not tested)
Without a tag qualifier (e.g. div[data-name]) your selector will be very inefficient as it will have to traverse the entire DOM to check for matching elements.
It would be much preferable to identify a specific ID (or even a class) to help out the selector engine and restrict how much of the DOM has to be searched.
As long as you don't repeat that everywhere, (i.e cache the result), I don't really see how you can get anything more DRY.
var name = $('[data-name]').data('name');
You're technically not repeating yourself yet.
Related
I was just wondering which is the correct or most efficient way of navigating through the Dom using variables.
For example, can I concatenate selectors
var $container = '.my-container';
$($container).addClass('hidden');
$($container + ' .button').on('click', function(){
//something here
});
or should I use the jQuery traversal functions
var $container = $('.my-container');
$container.addClass('hidden');
$container.children('.button').on('click', function(){
//something here
});
Is there a different approach, is one best, or can you use them at different times?
The $ is usually used only when working with an actual jquery object. You generally shouldn't prefix anything with that unless it's really something from jquery.
Beyond that little bit though, performance-wise, your second bit of code is going to be faster. I made an example jsperf here: http://jsperf.com/test-jquery-select
The reason the second bit of code is faster is because (if I remember correctly) jquery caches the selection, and then any actions performed on that selection are scoped. When you use .find (which is really what you meant in your code, not .children), instead of trying to find elements through the entire document, it only tries to find them within the scope of whatever my-container is.
The time when you wouldn't want to use the second pattern is when you expect the dom to change frequently. Using a previous selection of items, while efficient, is potentially a problem if more buttons are added or removed. Granted, this isn't a problem if you're simply chaining up a few actions on an item, then discarding the selection anyway.
Besides all of that, who really wants to continuously type $(...). It's awkward.
I have this line of code:
var filterInputs = $(this).siblings('.filterInputs');
which performs some work on filterInputs. Later on, I would like to reduce my collection of filterInputs to just those which are visible.
Clearly, I could do this:
var visibleFilterInputs = $(this).siblings('.filterInputs:visible');
but that seems inefficient given the fact that I already have a reference to the collection I was hoping to reduce.
Is there a way to say something like:
//TODO: Example
var visibleFilterInputs = $(filterInputs:visible);
without having to iterate over the DOM tree again? Thanks
You're absolutely right, there's no reason to recollect the DOM elements, since you already have them in a jQuery object. So that's exactly what the .filter() method is for: http://api.jquery.com/filter/
Try this:
var visibleFilterInputs = filterInputs.filter(":visible");
Here's an example: http://jsfiddle.net/FC9sH/
Note that it's better to target a certain HTML tag, such as <div>, to make the :visible selector a little more efficient (since it isn't part of the CSS specs and can't be optimized by native methods). At least in your case, you're already using the filterInputs class. Anyways, maybe something like:
var visibleFilterInputs = filterInputs.filter("div:visible");
but only if that's applicable. I mean, even selecting multiple known element tags is probably better:
var visibleFilterInputs = filterInputs.filter("div:visible, p:visible");
I've seen some JavaScript code to access HTML elements like this: elementID.innerHTML, and it works, though practically every tutorial I searched for uses document.getElementById(). I don't even know if there's a term for the short addressing.
At first I thought simplistically that each id'ed HTML element was directly under window but using getParent() shows the tree structure is there, so it didn't matter that elements I wanted were nested. I wrote a short test case:
http://jsfiddle.net/hYzLu/
<div id="fruit">Mango<div id="color">red</div></div>
<div id="car">Chevy</div>
<div id="result" style="color: #A33"></div>
result.innerHTML = "I like my " + color.innerHTML + " " + car.innerHTML;
The "short" method looks like a nice shortcut, but I feel there is something wrong with it for it practically not appearing in tutorials.
Why is document.getElementById() preferred, or may be even required in some cases?
Why shouldn't I access elements more “directly” (elemId.innerHTML)
Because, according to the others in this thread, referencing arbitrarily by id name is not fully supported.
So, what I think you should be doing instead is store their selections into a var, and then reference the var.
Try instead
var color = document.getElementById('color');
color.innerHTML = 'something';
The reason why this would be a good thing to do is that performing a lookup in the DOM is an expensive process, memory wise. And so if you store the element's reference into a variable, it becomes static. Thus you're not performing a lookup each time you want to .doSomething() to it.
Please note that javascript libraries tend to add shim functions to increase general function support across browsers. which would be a benefit to using, for example, jquery's selectors over pure javascript. Though, if you are in fact worried about memory / performance, native JS usually wins speed tests. (jsperf.com is a good tool for measuring speed and doing comparisons.)
It's safer I guess. If you had a variable named result in the same context that you are doing result.HTML I'm pretty sure the browser will throw a wobbler. Doing it in the way of document.getElementById() in this instance would obviously provide you with the associated DOM element.
Also, if you are dynamically adding HTML to the page I may be wrong, but you could also encounter unexpected behaviour in terms of what result is :)
Also I will add that not all ID's can have values that will not work as variable names. For instance if your ID is "nav-menu".
Although I suppose you could write window["nav-menu"].innerHTML
Which makes me think, what happens if you create a window level variable with the same name as an ID?
Checkout this jsfiddle (tested in chrome): http://jsfiddle.net/8yH5y/
This really seems like a bad idea altogether. Just use document.getElementById("id") and store the result to a variable if you will be using the reference more than once.
I have just finished my script, using flot and jquery. Now to my question, it is fast in opera and Firefox, but it is painfully slow in internet explorer (no surprise), so thats why I wonder if there is a way to make my script more efficient (In other words perhaps remove some of the "for loops" etc)? So if there are any code gurus out there who have some spare time to kill, please help me out, because I myself am terrible at writing efficient code :P
Thanks so much in advance =)
It can be found
on this address
A few more tips:
It was pointed out that:
... $(this).attr('id');
... $(this).attr('name');
is expensive, you don't need $ here at all, just use:
... this.id;
... this.name;
Also, using .css(...) is a huge waste, use a class and put the CSS in an style element.
You can store references like $('#x') in closures. Again, you don't need $, it's far more efficient to get a reference directly to the element using document.getElementByid so that rather than:
$('#x').text(pos.x.toFixed(2));
you can have:
x.innerHTML = pos.x.toFixed(2);
which replaces several function calls with a single property access. The basic idea is to remove as much jQuery as you can, keep references to things rather than getting them frequently and use direct property access, not functions.
Incidentally, when I try to copy from the jsFiddle javascript region, Safari freezes. I'm not a big fan of that site.
for(k; k<datasets.length; k++){
Every time the loop is executed next, you are calling the length property, it's better if you store it in a variable at the start of the loop only, like this:
for(var k, len = datasets.length; k < len; k++){
Also here you are wasting resources:
key = $(this).attr("id");
subsystem = $(this).attr("name");
just stich $(this) into a variable, cause every time you use $() a clone of the passed element is created. Just do like this:
var $this = $(this);
And use $this from there on instead of $(this), only reuse $(this) when this become a different object.
Firstly, with jQuery selectors, if using a classname, it's more efficient if you can make that more specific. e.g instead of
var checkboxContainerFailed = $(".failedCheckboxes");
try
var checkboxContainerFailed = $("#graph-table-bottom td.failedCheckboxes");
Secondly, it's generally considered better to use [] notation instead of var subsystemNames = new Array();
Thirdly, you have a trailing comma in the data array here. This might cause IE problems:
"test2-a4/",
]
Finally, try running the whole thing through JSLint for any errors.
$('#element').method();
or
var element = $('#element');
element.method();
Without using a profiler, everyone is just guessing. I would suspect that the difference is so small it isn't worth worrying about. There are small costs to the second above the first like having to preform a lookup to find 'var element' to call the method on, but I would have thought finding '#element' and then calling the method is far more expensive.
However, if you then went on to do something else with element, the second would be faster
//Bad:
$('#element').foo();
$('#element').bar();
//Good:
var e = $('#element');
e.foo();
e.bar();
If you were using a loop where the value of $('#element') was used a lot, then caching it as in the 2nd version before the loop would help a lot.
For just this small snippet, it makes little difference.
Lookups via id (#) are pretty fast. I just tested your scenario on a small page with 2 div tags. Here is the code i used
var x = $("#div1");
var y = $("#div2");
var z = $("#div1");
every lookup took about 0.3ms on my laptop. The 2nd lookup for div1 executed the same internal jQuery methods as the first - indicating that there is no caching of already looked up objects
Performance becomes a bigger problem when you use other selectors like classname or more advanced jQuery selectors. I did some analysis on jQuery Selector Performance - check it out - hope it is helpful.
If you run only this code, no one should realy be faster. The second one might need more memory (because of the additional variable created).
If you want to be sure, why not test it yourself using a small selfwritten benchmark?
I think $('#element').method(); does not need as much memory as
var element = $('#element');
... because you bind #element to a variable.
Juste fore funne
\Indifferent:
$('#element').foo().bar();