We Keep Coding

Why doesn't .then() need the async keyword when used (similar to await)? How does Javascript know it's an asynchronous operation?

I'm starting to learn asynchronous Javascript and I'm really confused.
To be honest, the async/await approach seems very logical to me. We need to let the runtime know we're doing an asynchronous operation so it can handle it accordingly. But why don't we need to do the same when using the .then() method? I mean, if Javascript was already able to understand when promises are handled, couldn't await just be used without async just like .then()?
To make it even more confusing, I saw people using .then() directly inside functions declared with the async keyword. Wasn't async/await supposed to be syntactic sugar for the .then().catch() approach? Why can these be combined, especially inside one another? Using .then() on the result of the async function wouldn't have been as confusing, but being inside one another makes me have even a harder time understanding this.
I really searched everywhere for an explanation on this and couldn't find an answer for this exact question. All I've found was people saying you can use both approaches because they essentially are the same thing, but when you get in the details, things aren't very clear.
So the async function always returns a promise. Inside it, await always handles promises. .then() can be chained to the await function. .then() can also be chained to the result of the async function. Same with the .catch method if we don't want to use try/catch on the await. Why is it so mixed up? Can we handle the return of async without .then()? If async/await really is syntactic sugar for .then(), why doesn't .then() also always return a promise after it resolves?
If anybody can help with some clarification, I would truly appreciate it. Thank you!

There's so many questions here, but one way to think about it is... Promises are not asynchronous operations, they are just a standard pattern that helps users deal with existing asynchronous operations in a predicable way.
There's nothing special about .then(). It's not a Javascript keyword, and javascript doesn't need to be 'aware' of then in any way.
Promises are a pattern. You can write a promise class yourself from scratch (I'd highly recommend this). When you use .then(), and you pass it a function, you are telling the promise class: "When the promise resolves, please call this function for me".
All of this existed before async/await. Async/await was added after to make it easier to work with promises.
I find the question if 'something is syntactic sugar' meaningless. It suggests that a language feature is not that meaningful because the same thing could be accomplished before the language feature existed. While this might be true, this is true for any programming language when compared to, say, assembly. To me the definition of 'syntax sugar' can be extended to almost anything, so it's not a useful designation.
What async/await (and generators before it) adds to the language, is that a javascript function can be interrupted and resumed later after some condition.
Lastly, .then() and .catch() always return promises. If you see a .then() function that doesn't, then it's not compatible with the Promise/A+ spec.
If you are willing to put in the work to fully understand this, I would recommend the following 2 exercises:
Write your own Promise class
Re-implement async/await using generator functions (see the co package of how this was done before async/await landed)

The purpose of async/await is to allow writing async code in a serial manner, which is mentally simpler to reason about (for some human-beings). This is useful, if you need to wait for async operation to finish before you continue with the rest of the code. For example, if you need to pass result of async operation as parameter.
Example 1
function asyncOperation1(n) { return Promise.resolve(n+1); }
function asyncOperation2(n) { return Promise.resolve(n/2); }
function asyncOperation3(n) { return Promise.resolve(n*3); }
function errorHandler(err) { console.error(err); }
function main() {
// flow-control
asyncOperation1(1)
.then(asyncOperation2)
.then(asyncOperation3)
.then(continueAfterAsync)
.catch(errorHandler)
// function wrapper
function continueAfterAsync(result) {
console.log(result);
}
}
main();
With async/await the code of the main function above may look like
async main() {
try {
console.log(
await asyncOperation3(
await asyncOperation2(
await asyncOperation1(1)
)
)
);
} catch(err) {
errorHandler(err);
}
}
Pay attention that we don't need to rewrite async operation functions to be async function asyncOperation... to use await, but we need to declare main function as async main.
Which one is better(?) is the mater of developers's taste and previous programming languages experience. The benefit that I can see is that you don't need to wrap everything into functions and introduce additional flow-control code, leaving this complexity to JavaScript compiler.
However, there are cases, when you want to schedule some parallel tasks and you don't care which one will finish first. These kind of things would be relatively hard to do with async/await only.
Example 2
function main() {
Promise
.all(
['srv1', 'srv2', 'srv3'].map(
srv => fetch(`${srv}.test.com/status`)
)
])
.then(
responses => responses.some(res => res.status !== 200) ?
console.error('some servers have problems') :
console.log('everything is fine')
)
.catch(err => console.error('some servers are not reachable', err))
}
So, we see that there is a room for both .then() and await to coexist.
In some cases function may be either synchronous or asynchronous, depending on business logic (I know it's ugly, but in some cases it's unavoidable). And here we come to your main question
why don't we need to mark an asynchronous operation with .then() and we have to do it with await
In other words, why do we need async keyword at all?
Example 3
// without `async`
function checkStatus(srv) {
if (!srv.startsWith('srv')) {
throw new Error('An argument passed to checkStatus should start with "srv"')
}
return fetch(`https://${srv}.test.com/status`);
}
function main() {
// this code will print message
checkStatus('srv1')
.then(res => console.log(`Status is ${res.status === 200 ? 'ok': 'error'}`))
.catch(err => console.error(err));
// this code will fail with
// Uncaught TypeError: (intermediate value).then is not a function
checkStatus('svr1')
.then(res => console.log(`Status is ${res.status === 200 ? 'ok': 'error'}`))
.catch(err => console.error(err));
}
However, if we define async function checkStatus, compiler will wrap the runtime error into rejected promise return value, and both parts of the main function will work.
Now let's imagine that JavaScript allows to write functions that use await without specifying async in front of them.
Example 4 (not a valid Javascript)
function checkStatus(srv) {
if (cache[srv]) {
data = cache[srv];
} else {
data = (await fetch(`https://${srv}.test.com/status`)).json();
}
data.x.y = 'y';
return data;
}
What would you expect checkStatus to return? Promise, raw value or throw exception (in case data.x is undefined)?
If you say Promise, then it would be hard for developer that uses this function to understand why inside of checkStatus one can write data.x and outside of it (await data).x is required.
If raw value, the whole execution flow becomes cumbersome, and you can no longer rely on the fact that JavaScript is a single-threaded language, where no-one can change the value of the variable between two lines of code that are written in serial manner.
As you noticed, async/await is a syntactic sugar. If this syntax allows me to avoid possible runtime errors at earlier stage and keep the language backward compatible, I'm eager to pay the price of putting extra async in front of async functions.
Also, I would recommend to read the answers to JS async/await - why does await need async?

In a simple explanation, async/await is syntactic sugar (the node interpreter/compiler/optimizer will convert everything to normal Promises).
The goal of this feature is turn our life easy, because the callback way/style of programming eventually lead us to make mistakes. We call this "the callback hell"
So, we can use .then() when calling functions that is decorated with async keyword, and we can await on functions that return Promise objects.
It's important for optimizations in general, that the code we write tells the compiler what we are meaning, in terms of performance. Imagine if all our codes / lines of code / instructions could be async or sync at the same time. This would lead the computers perform bad, because the task of check this during runtime is very expensive.
So that's why it's so important to us code instructions in an efficient manner.

Why should we wrap await inside an async function?

Why should we have an async function in order to use await? Why can't we just use await without async? JS is async by default too, this just adds to the confusion.
Update:
I've seen some lads put my question on hold so I'll try to elaborate.
I'm just curious as to why this won't work:
some code
let users = await getUsers();
some code
Why should it be inside an async for it to work, ie
$(async function() {
some code
let users = await getUsers();
some code
});

JS is async by default too...
No, JavaScript is not async by default. The only async features of JavaScript are fairly newly-added:
Promise resolution
async/await
JavaScript is commonly used in environments where you interact with asynchronous things (like event handlers in the DOM, or I/O completions in Node.js), but JavaScript is not asynchronous (other than above).
In the words of Allen Wirfs-Brock, who was the editor of the ECMAScript specification for many years, JavaScript...
(has) an observably synchronous execution model. Other than via Atomics/SABs there are no observable shared-state race conditions.
Back to your question:
Why should we have an async function in order to use await?
Before too long, with modules you won't have to, once the top level await proposal finishes working through the process. It just got to Stage 3.
But the answer is that await is syntactic sugar for consuming a promise, and one of the rules of promises is that you either handle errors or return the chain to the caller (so it can handle errors or return the chain to its caller). await doesn't handle errors, so it has to return the chain to the caller. The way it does that is that an async function always returns a promise, and that promise is chained to the promise await awaits.
That is, this:
async function foo() {
const thingy = await somethingAsyncReturningAPromise();
return thingy.foo;
}
is conceptually (but not literally) this:
function foo() {
return somethingAsyncReturningAPromise()
.then(thingy => thingy.foo);
}
If something goes wrong in somethingAsyncReturningAPromise, the promise returned by foo rejects — the error is propagated to the caller.
As far as I can tell from the top-level await proposal, it simply allows unhandled rejections at the top level of the module to be unhandled rejections. So just like this code causes an unhandled error:
null.doSomething();
this code in an async module would cause an unhandled rejection:
await somethingThatReturnsAPromiseAndRejects();

Why should we have an async function in order to use await? Why can't we just use await without async?
Because async/await is "just" syntactic sugar for Promises. If the function is async, then it returns a Promise. It is not possible to have the "await" behaviour without returning a promise. The fact that the function is async has to be marked explicitly.
JS is async by default too, this just adds to the confusion.
This statement is too "simplified". While it is true that JS is async in nature, because of the event loop, this doesn't mean that every function has an async behavior. This does not add to the confusion. You're probably confused due to misunderstanding how JS really works. You should read about Promises, which are behind the scenes when you see async/await.

JavaScript has task based concurrency. It basically means that code blocks (tasks) runs synchronously without being interrupted, until it reaches a certain breakpoint (the end of a task). That has some advantages:
1) You do have concurrency, e.g. a network call does not block your script from doing other things in the meantime (so the task that consumes the network request will only run if the network request was done, other tasks can be done in the meantime).
2) On the other hand, you do not have concurrent mutations, which eliminates a lot of problems (let a = 1; a += 1; could evaluate to 3, you would need locks / semaphores to prevent those, c.f. Java & others).
Now async / await allow you to define such tasks:
An async function can be divided into tasks, await serves as a breakpoint:
let a = 1;
async function stuff() {
a = a + 1; // this is totally secure, as no other code might run in the meantime
a = a + await other(); // this is unsafe, as we await, which means that other tasks might be executed in the meantime.
}
If you want to "await in non async functions" that basically means that you won't know wether a certain function call runs synchronously (meaning: without other code running in the meantime) or not:
function dangerous() { await stuff(); }
let a = 1;
a = a + dangerous(); // does that work or not? Can a be manipulated in the meantime?
So with your proposal you would basically remove the borders around tasks, every code might run every inbetween. So at the end that causes chaos, and chaos is not good if you want to be productive.

Unexpected Promise in React Native

I am new to React Native and coding in general. I paid for some code on upwork and am having a hard time integrating it in my program.
async pullBatch(since){
let param = {
userScreenName: '?screen_name=google',
count: "&count=5",
retweets: "&include_rts=false",
replies: "&exclude_replies=false",
trim: "&trim_user=true",
since: "&max_id=" + since
};
let twitterRest = new TwitterRest(); //create a new instance of TwitterRest Class
let batch = await twitterRest.pullTweets(param); //pull the Google TimeLine
return batch;
}
pullTimeline(){
let timeLine = []
for(i = 0; i <= 2; i++){
let currentBatch = this.pullBatch("1098740934588751900")
console.log(currentBatch);
timeLine = timeLine.concat(currentBatch);
}
console.log(timeLine);
// timeLine = currentBatch
return(timeLine)
}
I believe that when running pullTimeLine() the program is returning an array of three promises. (I have also run the code with "await" before pullBatch(), but it is erroring out telling me await is a reserved word) This means I am making two mistakes:
I am not correctly understanding promises in JS or how they are resolved.
I am incorrectly concatenating the arrays.
I am constantly trying to learn, so while I greatly appreciate suggestions for code fixes, I also really would appreciate if you'd teach me about where my lapses in understanding lies.
Thank you

Let's break it down. You seem to understand that pullBatch is an async function, and so calling it will return a promise create by the twitterRest interaction.
The problem is that your call to pullBatch inside your for loop will not resolve these promise (which seems to be what you want to do). The easiest way is to use await for currentBatch, but as you tried, you got the reserved error. Basically you just need to also make pullTimeline async like this:
async pullTimeline(){
...
Just realise that once you do this, pullTimeline is now an async function that will also return a promise. So to use this function you need to either use .then(), for example:
pullTimeline().then(timeLine => {
// do something with your timeline here
})
Or if you are using it within another async function, you can use await.
const timeLine = await pullTimeline() // must be inside async function
Basically at some point in your calling chain, you will have to resolve a promise using .then(), or disregard the top level promise by making a top level async function. For example:
async useTimeline() {
const timeLine = await pullTimeline()
// do something with your timeline
}
// call the function above, and just disregard its promise
useTimeLine()
Just don't forget to handle errors somewhere. Either use a .catch() on your top level promise, or use try / catch around any of your await calls.

How not to forget using await everywhere in Javascript?

Trying to write a little chrome extension, which relies on the callback-heavy query functions of the chrome.* interface, I quickly landed at promises and async/await, as I needed to guarantee the order of certain operations, while trying to avoid callback hell.
However, once I introduced async/await into some functions, every function that used them also had to be turned into an async function in order to be able to await the return value. Eventually even some global constants became promises, e.g.
const DEBUG = new Promise(function(resolve){
chrome.management.getSelf(resolve);
}).then(function(self){
return self.installType == 'development';
});
However, now I need to write await everywhere and introducing weird bugs like if(DEBUG){...} always being executed becomes way too easy.
While it seems possible to identify the errors using ESLINT, writing await everywhere seems unnecessarily cumbersome and thus I was wondering if Javascript has some better construct that I am missing?
(Subjectively my current use of await/async seems backwards; Promises are kept as-is unless explicitly awaited, but it seems more desirable to me to have promises awaited by default in async functions and kept as bare promises only when explicitly requested.)

For the lack of a type system that would allow to catch such mistakes easily (did you consider Typescript or Flow?), you can use Systems Hungarian Notation for your variable names. Choose a prefix of suffix like P, Promise or $ and add it to all your promise variables, similar to how asynchronous functions are often named with an Async suffix. Then only do things like
const debug = await debugPromise
where you can quickly see that if (debug) is fine but if (debugPromise) is not.
Once I introduced async/await into some functions, every function that used them also had to be turned into an async function in order to be able to await the return value. Eventually even some global constants became promises
I would not do that. Try to make as few functions asynchronous as possible. If they are not doing intrinsically asynchronous things themselves but only rely on the results of some promises, declare those results as parameters of the function. A simple example:
// Bad
async function fetchAndParse(options) {
const response = await fetch(options);
// do something
return result;
}
// usage:
await fetchAndParse(options)
// Good:
function parse(response) {
// do something
return result;
}
// usage:
await fetch(options).then(parse) // or
parse(await fetch(options))
The same pattern can be applied for globals - either make them explicit parameters of every function, or make them parameters of a module function that contains all others as closures. Then await the global promises only once in the module, before declaring or executing anything else, and use the plain result value afterwards.
// Bad:
async function log(line) {
if (await debugPromise)
console.log(line);
}
async function parse(response) {
await log("parsing")
// do something
return result;
}
… await parse(…) …
// Good:
(async function mymodule() {
const debug = await debugPromise;
function log(line) {
if (debug)
console.log(line);
}
function parse(response) {
log("parsing")
// do something
return result;
}
… parse(…) …
}());

Elegantly Handling Reject on `await`ed Javascript Promise

A great pattern with ES2017 async/await is:
async function () {
try {
var result = await some_promised_value()
} catch (err) {
console.log(`This block would be processed in
a reject() callback with promise patterns
but this is far more intuitive`)
return false // or something less obtuse
}
result = do_something_to_result(result)
return result;
}
Being able to handle errors like that is really nice. But say I want to asynchronously get a value I'd like to protect it from reassignment (eg: a database session), but I still want to use the async/await pattern (purely because I think it's far more intuitive).
The following won't work because const is block scoped:
async function () {
try {
const result = await get_session()
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
return false
}
// Can't get at result here because it is block scoped.
}
Of course you could execute the rest of the function within the try block, but then you risk errors getting caught that should be let fall through somewhere else. (For example I hit this challenge writing tests where errors like test failures need to fall back to the test suite but wanted to handle driver instantiation myself. Perhaps I'm falling into some kind of anti-pattern here by not letting those errors fall back to the test suite.)
The simple answer obviously is don't use that pattern here. Use Promises and callbacks instead. Or use a var and avoid block scoped const and let. But I like the benefits of reassignment protection and block scope for other considerations.
[question]: Is there a way to wrap an await/async try/catch block to every function? Seems to be one potential solution, but doesn't quite come up as readable as try/catch. The fact that try/catch doesn't break function scope and I can use return from within a try/catch block seems to me to be more in line with the spirit of async/await bringing a more procedural-looking logic to asynchronous code.
Ideally you'd want to do something like const x = await y() catch (err) or const x = await y() || fail But I can't think of anything with a similar flow that's syntactically correct.
UPDATE:
As suggested by #jmar777 below another alternative is:
const x = await y().catch(() => {/*handle errors here*/})
Which is probably the closest I've found to those last two examples in practice. But it breaks the return scope that blocks downstream execution in the examples above. Which is a nice synchronous-like way of handling things.
Each solution has its trade offs.
I've manually hoisted the variables with let at the top of the function block as a working solution (as described in jmar777's answer) still an interesting question to see the various approaches, so I'll leave the question open for now.

You may have a misunderstanding regarding the benefits of using const. Assigning a value using a const declaration doesn't make that value immutable, it simply means that the value of that constant can't be changed or redeclared:
The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned. For instance, in case the content is an object, this means the object itself can still be altered. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)
In your example, you're probably best off manually hoisting your result binding outside of the try/catch:
async function () {
let result;
try {
result = await get_session()
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
}
// do whatever else you need with result here...
}
An alternative would be to restructure the code such that you don't need to rely on a try/catch at all. For example:
async function () {
const result = await get_session().catch(someRejectionHandler);
// do whatever else you need with result here...
}
Just be aware that your downstream code needs to gracefully handle the case where get_session() was rejected, and result isn't initialized based on a successful response. This is no different than in your initial example, but perhaps not quite as obvious when scanning the code.

Coming back to this question a few years later a far simpler answer has occurred to me, I don’t see in retrospect why I was interested in a small try/catch pair and then performing more logic outside of it when I could simply perform all the logic and return inside the try statement.
Taking the example from the question and applying that structure it would be:
async function () {
try {
const result = await get_session()
// Do what needs to be done and then:
return result
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
return false
}
}
If you need to access anything from the try block in the catch block raise it in an error. There may be a reason I needed to move out of the try scope when I asked this question, but I can’t see a scenario that would necessitate it looking back. This solution wouldn’t work if you were to use try/catch/finally and return in finally. But I don’t think I’ve come across that pattern much at all in the wild.