How the code is executed

setInterval((function() {
        var index = -1;
        return function() {
            var all = $('#latest a');
            if (index >= 0) {
                all.eq(index).hide();
            }

            index++;
            if (index == all.length) {
                index = 0;
            }

            all.eq(index).show();        
        };
    })(), 1000);

how the code is executed? when index = -1; it not fits the first if condition, then the code goes to execute index++; now the index=0, then which step the code will be executed? if (index >= 0) or if (index == all.length) why?

Hard to decipher what you’re asking thanks to the Engrish, but since the interval function resets it to -1… it will be -1 whenever the interval goes off… Not sure what you’re trying to accomplish with that – especially the return function since interval events don’t take a return.

That code is gibberish… just what are you trying to do? (apart from slow the page to a crawl by using “all” and bloating out the page with jquery nonsense?)

The first part of the code executes straight away as it is a self executing function. The function that is returned is then passed to the setInterval to process a second later. So index is set to -1 at the start and that is then accessed a second later via a closure from the function that the setInterval runs.

By wrapping the code in a self executing function like that and creating index within that function it is only accessible from within that function. One way to create a closure so as to extend the use of a private variable like that is to return a function and that code actually rather cleverly returns the function to use in the setInterval.

So basically index is set to -1 now and then one second later and every second after that the following code is run:

var all = $('#latest a');
            if (index >= 0) {
                all.eq(index).hide();
            }

            index++;
            if (index == all.length) {
                index = 0;
            }

            all.eq(index).show();

Deathshadow just isn’t as up to date with his understanding of JavaScript as he is with HTML and CSS. Apart from that code using jQuery when the person who wrote it obviously knows enough to be able to write their own equivalent for just the part of the library they need, there is nothing wrong with that code. It is just about the only way that you could implement code to run every second that needs to pass a value between iterations in an unobtrusive manner.

Actually, I just missed the immediate execute () – without which it doesn’t make a whole lot of sense. That could be what the OP is missing as well on this… when you }() at the end of a function, it means ‘execute this function immediately as an object’ – the return then providing the function that is actually run. For some bizzare reason when you do that the object is not disposed and any vars you declare in it are preserved – indefinately. (basically until the page is unloaded) – this is why it’s dangerous to make that type of call inside a loop. (I’ve seen people do it… wondering why it crashes the browser after a few minutes).

Normally I attach properties to be passed to the parent element… along with any such functions. It adds to the namespace, but at least it’s down-tree addition in the DOM reducing the odds of conflicts.

for example:


var parent=document.getElementById('latest');
parent.aAll=parent.getElementsByTagName('a');
parent.aIndex=0;
parent.aAll[0].style.display='inline';
parent.aIntervalHandler=function() {
	with (this) {
		aAll[aIndex].style.display='none';
		aIndex=(aIndex++)%aAll.length;
		aAll[aIndex].style.display='inline';
	}
}

Which in “let’s tack a fatass bloated library to it” would be:


var parent=$('#latest');
parent.aAll=$('#latest a');
parent.aIndex=0;
parent.aAll.eq(index).show();
parent.aIntervalHandler=function() {
	with (this) {
		parent.aAll.eq(index).hide();
		aIndex=(aIndex++)%aAll.length;
		parent.aAll.eq(index).show();
	}
}

I can see the advantage of using a self-constructing object’s namespace to handle it if you’re only calling this once – though said object (and at that point the outer function is an object) never releasing itself from memory means you’re relying HEAVILY on the browsers garbage collection. (Meaning train wreck in FF). Still, the biggest issue I see is constantly calling the list selection INSIDE the function. If you can preserve index between them, you should be able to preserve ALL as well.


setInterval((function() {
	var
		index=0,
		all=document.getElementById('latest').getElementsByTagName('a'),
		all[0].style.display='inline';
		
	return function() {
		all[index].style.display='none';
		index=(index++)%all.length;
		all[index].style.display='inline';
	}
}(),1000);

Or with the idiotic bloated needlessly cryptic library that flushes 90%+ of the websites it’s used on…


setInterval((function() {
	var
		index=0,
		all=$('#latest a'),
		all.eq(0).show();
		
	return function() {
		all.eq(index).hide();
		index=(index++)%all.length;
		all.eq(index).show();
	}
}(),1000);

Which is a pretty slick way of handling it… All those unnecessary conditionals and calling up the list on every interval seemed needlessly complex. Coding 101, do as little inside the loop as possible. This way also means you’ll have a link showing BEFORE the second of the first interval is up. This does have the issue that if you’re adding/removing those anchors via scripting it will fail on you though… but since they are anchors that means they are content – which means you have little if any business adding/removing them with scripting in the first place.