before doing some calculations and inserting new elements after the $(parentSelect). My calculations are incorrect if the existing elements are still visible to jQuery and sleeping/delaying some arbitrary amount of time (200 for each element) seems like a brittle solution at best.

I can easily .bind() the necessary logic to an event callback but I'm not sure how to cleanly invoke the .trigger() after the above iteration has completed. Obviously, I can't invoke the trigger inside the iteration as it would fire multiple times.

In the case of $.each(), I've considered adding something to the end of the data argument (that I'd manually look for in the iteration body) but I'd hate to be forced to that so I was hoping there was some other elegant way to control the flow with respect to iterative callbacks.

Do I correctly understand that it's not so much the ".each()" itself that you want to finish, but rather all the animations launched by the ".each()" call?
–
PointyMar 1 '10 at 19:01

That is a good point. With this particular question, yes, I am mainly concerned about the completion of ".each()" itself ... but I think you raise another viable question.
–
Luther BakerMar 1 '10 at 19:50

Note that .each() itself is synchronous — the statement that follows the call to .each() will be executed only after the .each() call is complete. However, asynchronous operations started in the .each() iteration will of course continue on in their own way. That's the issue here: the calls to fade the elements are timer-driven animations, and those continue at their own pace.

The solution above, therefore, keeps track of how many elements are being faded. Each call to .fadeOut() gets a completion callback. When the callback notices that it's counted through all of the original elements involved, some subsequent action can be taken with confidence that all of the fading has finished.

This is a four-year-old answer (at this point in 2014). A modern way to do this would probably involve using the Deferred/Promise mechanism, though the above is simple and should work just fine.

I like this change, though I'd make the comparison to 0 instead of the logical negation (--count == 0) since you're counting down. To me it makes the intent clearer, though it has the same effect.
–
tvanfossonMar 1 '10 at 22:37

As it turns out, your initial comment on the question was spot on. I was asking about .each() and thought that is what I wanted but as you and tvanfosson and now patrick have pointed out - it was the final fadeOut that I was actually interested in. I think we all agree that your example (counting instead of indexes) is probably the safest.
–
Luther BakerMar 2 '10 at 6:40

@A.DIMO What do you mean by, "too complicated"? What part is complicated?
–
PointyOct 8 '14 at 14:08

Javascript runs synchronously, so whatever you place after each() will not run until each() is complete.

Consider the following test:

var count = 0;
var array = [];
// populate an array with 1,000,000 entries
for(var i = 0; i < 1000000; i++) {
array.push(i);
}
// use each to iterate over the array, incrementing count each time
$.each(array, function() {
count++
});
// the alert won't get called until the 'each' is done
// as evidenced by the value of count
alert(count);

When the alert is called, count will equal 1000000 because the alert won't run until each() is done.

The problem in the example given is that the fadeOut gets put on the animation queue and doesn't execute synchronously. If you use an each and schedule each animation separately, you still have to fire the event after the animation, not the each finishes.
–
tvanfossonMar 1 '10 at 22:35

2

@tvanfosson - Yeah, I know. According to what Luther wants to accomplish, your solution (and Pointy's) seems like the right approach. But from Luther's comments like... Naively, I'm looking for something like elems.each(foo,bar) where foo='function applied to each element' and bar='callback after all iterations have completed'. ...he seems insistent that it is an each() issue. That's why I threw this answer into the mix.
–
user113716Mar 1 '10 at 22:58

You are correct Patrick. I did (mis)understand that .each() was scheduling or queuing my callbacks. I think that invoking fadeOut was indirectly leading me to that conclusion. tvanfosson and Pointy have both provided answers for the fadeOut problem (which is what I was really after) but your post actually corrects my understanding a bit. Your answer actually best answers the original question as stated while Pointy and tvanfosson answered the question I was trying to ask. I wish I could pick two answers. Thanks for 'throwing this answer into the mix' :)
–
Luther BakerMar 2 '10 at 6:45

@user113716 I thought functions inside each were not guaranteed to be called before alert. could you explain or point me to the reading on this?
–
Maciej JankowskiApr 6 '14 at 9:10

I found a lot of responses dealing with arrays but not with a json object. My solution was simply to iterate through the object once while incrementing a counter and then when iterating through the object to perform your code you can increment a second counter. Then you simply compare the two counters together and get your solution. I know it's a little clunky but I haven't found a more elegant solution so far. This is my example code:

This would work - although, not what I'd hoped. Naively, I'm looking for something like elems.each(foo,bar) where foo='function applied to each element' and bar='callback after all iterations have completed'. I'll give the question a bit more time to see if we come across some dark corner of jQuery :)
–
Luther BakerMar 1 '10 at 19:56

AFAIK - you have to trigger it when the "last" animation completes and since they run asynchronously, you'd have to do it in the animation callback. I like @Pointy's version of what I wrote better since it doesn't have the dependency on the ordering, not that I think that would be a problem.
–
tvanfossonMar 1 '10 at 22:38

This definitely invokes myfunction() once (and introduces me to another jQuery concept) but what I was looking for was a guarantee of 'when' it would run - not merely that it would run once. And, as Patrick mentions, that part turns out to be pretty easy. What I was really looking for was a way to invoke something after the last fadeOut logic ran which, I don't think .one() guarantees.
–
Luther BakerMar 2 '10 at 6:33

I think that the chain does that - since the first part runs before the last part.
–
Mark SchultheissMar 2 '10 at 12:36