@Piotr Poźniak @Uczynny Kot
Wersja z promise:
function doStuff () {
database
.read('value')
.then(result => process(result.text))
.then(success => {
if (success) {
console.log('OK')
}
})
}
doStuff()
CodePen: https://codepen.io/caderek/pen/OOpRPJ?editors=0012
Wersja z async-await:
async function doStuff () {
const result = await database.read('value')
const success = await process(result)
if (result) {
console.log('ok')
}
}
doStuff()
CodePen: https://codepen.io/caderek/pen/MOpjev?editors=0012
Jak widać nie ma zagnieżdżeń i nic na nic nie czeka w przypadku async-await bardziej niż w wersji z callbackami i promisami (patrz kolejność wykonania console.log na CodePenie).
database.read
jak widać wcale nie musi być oznaczone jako async
- wystarczy, że zwróci promise (nawet jak nie zwraca i nie możesz jej przerobić to łatwo ją w promisa opakować).
Tłumaczyć jak async-await działa raczej nie będę, bo te informacje można ławo wyszukać.
A co do przykładu użytkownika @Piotr Poźniak - jest zagnieżdzony głównie ze względu na korzystanie z domknięć, możnaby go spłaszczyć przekazując dane w parametrach - czy będzie to czytelniejsze cięzko powiedzieć. Bez lepszego przeanalizowania ciężko też powiedzieć, czy rozwiązanie jest w ogóle optymalne. W każdym razie nie wiem czego ten przykład ma dowodzić ;)
@Bogaty Kret
Jasne, można po prostu przypisać callbacki do zmiennych, ale kod nadal będzie mniej czytelny, rozlazły i trzeba będzie wymyślać dodatkowe nazwy zmiennych (to akurat mniejszy problem, bo ogólnie nazwane funkcje często są wskazane, choć czasem jest to sztuczny szum jak callback jest prosty). Dlatego promisy i async-await to nie kombinowanie, a sposób na lepszej jakości kod.
Przykład z nazwanymi callbackami dla pełnego obrazu:
function doStuff () {
database.read("value", doSomethingWithResult)
}
function doSomethingWithResult (result) {
process(result.text, displayStatus)
}
function displayStatus (success) {
if (success) {
console.log('OK')
}
}
doStuff()
CodePen: https://codepen.io/caderek/pen/pdeEqa?editors=0012