Yes, this is a "fancier" way I had in mind, but I rarely ever use bind anymore because arrow functions so it doesn't come as easy, nice!

Index, nice, going to remember that!

[3rd argument] - I used this once for something very specific and I forget what, but at the time it seemed like magic!

Thanks. That works. Can someone explain why the first one didn't work? "promise1.then" can't happen after the loop is finished for the last time if it's inside the promise callback function? How is this different than the next to the last time? The loop is actually done before that time as well, no?

I've never seen a promise.then called inside the definition of the promise.

I never had an idea what a promise was until I heard it on Javascript Jabber yesterday. I've been on semi-hiatus since about 2005. Just trying to get a handle on it and wonder why it specifically worked all but the last time.

Ok lets walk through it. I suspect what's happening is the 0 is actually being spit out on the second pass, so it never gets to the last pass. Which we can verify by reducing the loop size to 2:

Output: 0. So that confirms the first pass is doing nothing. Why? Well lets take the loop out of the equation and think about it:

Output: (nothing, as expected). Is it something weird caused by the setTimeout? Doesn't feel like it, but let's take that out of the equation:

Output: (still nothing). What's left? Maybe it's something weird in that we're referencing var promise1 inside its own definition. So let's test for with a console.log:

Output: undefined. So yeah that confirms it. What happens is it's not defined yet the first time through on the loop. On the second time through it's actually executing the promise1 you defined on the first time through - hence output: 0. It makes sense that a variable wouldn't be defined yet, until its definition block is done being interpolated by the compiler.

So why doesn't it throw an error on the first pass? Well all I can think of is maybe the Promise constructor swallows exceptions. So let's test for that by wrapping the .then definition in a try/catch block:

Output:
Yep - the Promise constructor is swallowing the exception. Bad Promise constructor. I guess the JS overlords are do as I say, not as I do.

Let's wrap the whole thing in a try/catch block, just on the off chance it's some weird codepen sandbox behavior that's causing the error not to show up:

Output: nothing. So yeah, not a weird codepen thing.

So just for fun let's add the loop back in with the try/catch block:

Output:
You can play around with it here: https://codepen.io/anon/pen/oPdaPm?editors=0012

Really digging codepen over jsFiddle. The only thing you need to make sure to do is change Settings: Behavior to not enable Auto-Updating Preview.

Wouldn't this only execute `callback` on child-less nodes?

What would arrow function binding look like?

Does arrow function capturing have different rules that would make the above do the right thing? Or would it be like suzzer's function-in-yo-function thing in arrow syntax?

I recall that arrow functions bind `this` "correctly", as opposed to older syntax requiring stupid "var thiz = this" stuff, but not sure if anything else differs.

You need a factory function to get the scoping to work right if you're using a variable that is not block scoped, even with arrow functions, e.g.

But of course if you're allowed ES6 then you should just let i = 0...

Suzzer,

Thanks. In the podcast they talked about the issues with error catching and promises. One of the guests was there talking about Async/Await and I think that makes error handling easier.

I'm going to verify I get this on the code that worked:

for (i=0;i<5;i++) {
var promise1 = new Promise(function(resolve, reject) {
setTimeout(resolve(i), i*100);
}); HERE
promise1.then((successMessage) => {
console.log(successMessage);
});
}

Now, my vocabulary probably sucks and any corrections are more than welcome, it's not until HERE that the "promise1" object is defined and only after that point can its "then" method be called.

?

And, wow, JSFiddle looks cool. Man people have spent a lot of time developing tools in the last 13 years.

Yup I'm an idiot

Micro, yes, because as you can see you are creating the variable promise1 and assigning it to a new instance of Promise. That assignment is not complete until the block closes - }); So you can't put an instance of the variable inside the definition.

It's like telling someone "Make a ball and call it George: #1 get some plastic. #2 Heat plastic. Now bounce George! #3 Pour into mold. #4 Let cool."

George isn't even created yet so you can't bounce him.

The more I read this thread, the less I like javascript.

(don't be confused by the minute of ruby at the beginning :P)

Count me in on the JavaScript hate train. I don’t know how you guys do this day in and day out.

That video’s amazing, i want more

All of our JS discussions here are way deeper into the pointlessly arcane than my day to day use of the language. It probably creates a slightly skewed perception. Some of that, I think, is just that JS devs consume libraries and do other things to sort of polish off the rough edges and avoid the weird parts. Some of it is the tendency of interview questions to explore the arcane bits. Also everything seems much worse if you have to support like IE9 or some ****.

Although, I think understanding variable scoping for asynchronous execution is probably pretty important, even if the specific example is contrived.

we dont do this day in day out or really ever. at least I dont, and I use Javascript all day pretty much.

Take this with a grain of salt ofc, but this with arrow functions basically isn't a thing. So using this in an arrow function is just a lexically bound meaning of this.

In react that's important for stuff like click events, where you are calling a method that's on the class, but calling it from the dom where this is mostly window. So you need to bind that event's this reference in the class's constructor. With arrow functions you get that binding with less characters.

Interestingly, on a Dan Abramov podcast they were discussing performance impact of binding in constructor and using an arrow function and another guest said the arrow function was more performant. Abramov quickly corrected that, saying he "would not be confident that is correct" and it started a quick discussion about which strategy was actually more performant, which they all said they had no direct idea. I tried to research it quickly and wasn't able to find what I was looking for (an autistically detailed explanation of the exact inplementations).

I was reading code a 30+ year dev wrote at my last company for a last minute project and she was both using arrow functions AND binding in the constructor. THAT I'm pretty sure is a performance penalty where you end up with at least an extra copy of every method you dont need (maybe two?) but I wasnt even sure that it didnt somehow get parsed out more efficiently by the interpreter.

I also found a bunch of binding inside JSX but the performance issues with that are more obvious (every re-render causes you to store an extra copy of that function).

Yea I guess I could probably conjure up some obscure and weird C code examples. I did a project for a website from scratch earlier this year and I heavily used vanilla JS. I really, really didn’t like it or the tools at all.

FYI - if anyone gets a job I'll split the referral bonus with you.

Hah, must feel good to be able to spam recruiters for a change!

Quick yes/no!

I might have to create a new LinkedIn account just to do that. Anyone have experience in creating fake LinkedIn profiles?

I was told by someone who uses several that "it's much harder now than it used to be".

She saw it as essentially "growth hacking" and had accounts of hot chicks she used for getting the first response and then quickly handing it off. Random people would be using the account and then handing the leads off (often to themselves).

I thought it was meh fine, but kinda shady and not the type of thing I would plan to do longterm at all.

FYI - I posted that for the $1500 referral thing, not the $15000.