Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

its interesting that when people talk about the newest feature or framework in javascript, they tend to forget about javascript's core functionality. It's always necessary to look at things like promises with javascript's core functionality in mind. Take #3 for example, which is really just a function of the core way javascript executes, taking promises aside!

You would not do something like this would you in a normal day at the office? function myFunction(doSomething()){

};

so why would you do this.

Promise.then(doSomething());

doSomething() gets immediately invoked when the code is evaluated. It has nothing to do with Promises.

Don't forget the fundamentals!



This article has a lot of ambiguity which I think adds to the confusion.

For example I was looking at that question(3) thinking, does doSomethingElse() return a function, another promise, nothing?

Part of the problem of having a very forgiving, lose language and API is that it leads to hidden, subtle complications, highlighted by "Advanced mistake #5: promises fall through". Here the then() method accepts anything as a return type, but will only chain a function that returns a promise, not a promise it's self. This isn't present in the MDN documentation (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).


This. That was my "answer" to the question. "Oh, if `doSomethingElse()` returns a function, it will run that function after the promise resolves successfully."


Well, not necessarily. Let's say doSomething is a closure that itself returns a function. Then it makes perfect sense to call it that way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: