Promises vs Async/Await in React

Question

All the official documentation and examples I saw so far use Promises for asynchronous executions, for example (from The Road to Learn React book):

class App extends Component {
    //...
    fetchSearchTopStories(searchTerm, page = 0) {
        fetch(`${PATH_SEARCH}?${PARAM_SEARCH}${searchTerm}`)
            .then(result => this.setSearchTopStories(result.data))
            .catch(error => this.setState({ error }));
    }
    //...
}

Why are Promises the preferred way? It there anything to prevent from using async/await in this manner?:

class App extends Component {
    //...
    async fetchSearchTopStories(searchTerm, page = 0) {
        try {
            const result = await fetch(`${PATH_SEARCH}?${PARAM_SEARCH}${searchTerm}`);
            this.setSearchTopStories(result.data);
        } catch (error) {
            this.setState({ error });
        }
    }
    //...
}

Answer 1

Javascript's purpose has been, for quite some time already, of being a multi-paradigm language (although it was often classified as a functional one due to its constructions being more easily associated to this specific paradigm). For instance, not that long ago JS's support for the object-oriented programming approach was existent but notoriously hacky, as you would declare a function and give it methods, attributes, etc, which would enable that function to actually work as, and be, a class (although a somewhat strange, anti-intuitive one).

However, javascript has been growing a lot in popularity lately, which notoriously began after the world became conscious of node.js's potential, and, in response to this, the people responsible for ECMAScript (JS's official standard) started to take consistency and de facto multi-paradigm support a lot more seriously, and then ES6 was launched in 2015 aiming to address the hacky, unstandardized constructs so common (and so criticized) in javascript's environment.

With ES6 came a more obvious support for object-orientation (such as the class keyword for example), but, given JS's bad reputation with its multi-paradigm support so far, the ECMAScript committee was clearly trying to compensate. The await keyword is an effect of this attempt, as asynchronous programming in JS has usually been made via the functional approach, chaining one function after another, each executing once the previous function finished its execution (an approach which makes a lot of sense, since things such as requests to external servers cannot have their exact response time reasonably predicted). await offers a possibility of a structured approach to this problem (in a very simplified explanation, structured programming means "one line of code instantly executing after another"), as fetch without await would return an unsolved promise and the code would follow its execution ignoring fetch's actual response, but with the await keyword in place the code will cease to execute until the actual response comes (the external server's data or an error, not a promise).

Therefore, even though they can be considered equivalent, the functional approach has been around for more time and so it is the JS way to do things.

Answer 2

While the same results can be achieved with both (promises and async/await), there are still minor differences between them:

• Only the promise chain itself is asynchronous <=> The entire async wrapped function is asynchronous

Promises exist longer than async/await style, there are more examples and it works.

I personally prefer the await/async style, because it looks much cleaner and the error handling is better, especially when chaining.

But in the end it does not matter which one you use, both will work.