Babel Coder

กำจัด Callback Hell ด้วย Promise และ Async/Await

intermediate

สวัสดี… เรา Callback Hell เอง

ผมเชื่อว่าหลายคนอาจเคยตกอยู่ในสถานการณ์นี้ที่โค๊ด JavaScript ของคุณอุดมไปด้วย Callback ยิ่งหากเป็น Callback ซ้อนกันอยู่หลายๆชั้นเช่นโค๊ดด้านล่าง ยิ่งลำบากต่อการอ่านและแก้ไขโค๊ด

สำหรับท่านใดที่ไม่เคยเจอกับปัญหาแบบนี้มาก่อนเพราะไม่ทราบว่า Callback คืออะไรวะแก ผมแนะนำให้เพิ่มความสับสนใส่ตนเองด้วยการอ่านบทความ รู้ซึ้งการทำงานแบบ Asynchronous กับ Event Loop

User.findById(userId, (err, profile) => {
  if(err) console.err(err)
  // โค๊ดนี้เป็นใช้เป็นตัวอย่าง Gravatar ไม่ได้รับ email ผ่าน URL ตรงๆ
  fetch(`http://www.gravatar.com/avatar/${profile.email}`, (err, avatar) => {
    if(err) console.err(err)
    User.update(userId, avatar, (err, res) => {
      if(err) console.err(err)
      doXXX(() => {
        doXYZ(() => {
          // .....
        })
      })
    })
  })
})

Callback Hell คือเจ้าสถานการณ์เช่นที่ว่า และเพื่อให้บทความนี้ดูน่ารักมุ้งมิ้ง ผมขอเรียกตัวละคร Callback ของเราว่า น้องคอลลี่ และเรียกเจ้าปัญหานี้เป็นภาษาไทยเก๋ๆว่า ความหม่นหมองของน้องคอลลี่ แล้วกัน

Callback เกิดขึ้นได้อย่างไร

พื้นเพของน้องคอลลี่นั้นเป็นเด็กเสี่ย ป๋าขา เสร็จธุระแล้วเรียกหนูนะคะ จึงเป็นสโลแกนของน้องคอลลี่

Callback เป็นฟังก์ชั่นที่ส่งเข้าไปในฟังก์ชั่นอื่นและพร้อมทำงานเมื่อ ป๋าเสร็จธุระแล้ว ตัวอย่างจากโค๊ดข้างบนคือ เรามีฟังก์ชั่น findById ทำหน้าที่ร้องขอข้อมูลผู้ใช้งานระบบ เพื่อที่จะนำอีเมล์ไปดึง avatar จากบริการของ Gravatar ถัดมาในบรรทัดที่4 พบว่าเราจะขอรูปจาก Gravatar ได้ต้องมีอีเมล์ก่อน เหตุการณ์ fetch Gravatar จึงต้องเกิดหลัง findById เช่นนี้จึงสร้างน้องคอลลี่ครอบฟังก์ชั่นดังกล่าวดังนี้

// err ส่งเข้ามาเมื่อมี error เกิดขึ้น
(err, profile) => {
  fetch(`http://www.gravatar.com/avatar/${profile.email}`, (avatar) => {
    ...
  }
}

เนื่องจากน้องคอลลี้ต้องรอให้ป๋า findById ได้รับข้อมูล profile ก่อน เราจึงโยน Callback นี้ไปเป็นพารามิเตอร์ของ fetch Gravatar เพื่อให้ป๋าเรียกใช้งานเมื่อ…เสร็จ ดังนี้

User.findById(userId, (err, profile) => {
  fetch(`http://www.gravatar.com/avatar/${profile.email}`, (avatar) => {
    ...
  })
})

จากโค๊ดทั้งหมดจึงสรุปได้ว่า เราร้องขอ profile ของ User ก่อนเพื่อเอาเฉพาะอีเมล์ไปดึง avatar จากบริการของ Gravatar จากนั้นจึงนำรูป avatar ไปอัพเดทข้อมูลผู้ใช้งานที่มี ID เป็น userId เมื่อทุกอย่างเรียบร้อยจึงค่อยทำ doXXX และ doXYZ ในลำดับถัดไป

ฟังแล้วเหนื่อยกับการเรียบเรียงลำดับความคิดใช่ไหม ในวันข้างหน้าหากเราต้องการแก้ไข doXYZ เราต้องขึ้นไปไล่ดูว่ามีอะไรเกิดขึ้นก่อนหน้านี้บ้าง ซึ่งเป็นเรื่องยากเพราะ Tab เยอะเหลือเกิน แถมน้องคอลลี่แต่ละนางก็เปลือยเปล่าไม่รู้ว่าชื่ออะไรบ้างมีแค่ (profile) => {...} หรือ (avatar) => {...} ที่เราไม่เข้าใจว่าตัวตนของน้องเขาคือใคร จนกว่าจะได้สัมผัสเนื้อตัว อ่านค้นโค๊ดข้างในให้ทะลุถึงจิตใจและตับไตไส้พุงป่ามป้ามของเธอ

ความพยายามครั้งที่ 1

หลงรักน้องคอลลี่ไปแล้วคงตัดใจได้ยาก ถ้ามันเข้าใจยากนักเราก็ตั้งชื่อให้น้องเสียเลย ลองมาพยายามกันเถอะ

const userId = 13

const updateAvatar = (err, avatar) => {
  if(err) console.err(err)
  User.update(userId, avatar, doXXX)
}

const getCurrentGravatar = (err, profile) => {
  if(err) console.err(err)
  fetch(`http://www.gravatar.com/avatar/${profile.email}`, updateAvatar)
}

const getUser = (userId) => {
  User.findById(userId, getCurrentGravatar)
}

getUser(userId)

จุดนี้น้องคอลลี่ดูฟรุ้งฟริ้งขึ้นทันที เมื่อเรากลับมาอ่านโค๊ดอีกครั้งทุกอย่างดูเข้าใจได้ง่ายขึ้น เรารู้ได้ว่าโค๊ดแต่ละส่วนคืออะไรโดยอาศัยการเดาจากชื่อที่ตั้ง นอกจากนี้ยังเป็นการลดจำนวน Tab ที่น่าปวดหัวลงได้มาก

ตัวอย่างข้างต้นเราเพียงใส่ userId โปรแกรมของเราจะเริ่มหา profile เพื่อไปร้องขอ Avatar แล้วนำมาอัพเดท user ดั่งที่คาดหวังไว้

ถ้าทุกอย่างสมบูรณ์ไปหมด บทความนี้คงไม่เกิดขึ้น โค๊ดข้างต้นนั้นจะเกิดปัญหาเมื่อเราแยกฟังก์ชั่นยิบย่อยมากกว่านี้ ลองจินตนาการว่าหลังจากเราเรียก getUser(userId) แล้วมันไปเรียกฟังก์ชั่นอื่นให้ทำงานอีกซัก10แห่ง โปรแกรมเมอร์อย่างเราต้องกวาดสายตาขึ้นลง เพื่อหาฟังก์ชันน้องคอลลี่ที่เล่นซ่อนแอบอยู่ที่ไหนซักแห่งในไฟล์ เช่น ในบรรทัดที่2 หากเราประกาศ doXXX ไว้บนสุด เราต้องกวาดสายตาค้นหาว่าฟังก์ชันนี้นิยามไว้ที่ใด เป็นต้น

ปัญหาอีกประกาศคือการแบ่งแยกงานที่ไม่ชัดเจน ทุกครั้งที่เราเรียก getCurrentGravatar มันจะเรียก updateAvatar เสมอนั่นหมายความว่า หากเรามีโค๊ดชุดอื่นที่ต้องการ getCurrentGravatar เหมือนกัน ต้องการแค่นำรูปไปใช้แต่ไม่ต้องการอัพเดทรูปจะทำไม่ได้!

นอกเหนือจากนี้เรายังส่ง err เข้าไปในทุกฟังก์ชันที่เกี่ยวข้องซึ่งมันไม่สมเหตุผล เหตุเพราะไม่มีความจำเป็นใดๆที่ updateAvatar และ getCurrentGravatar ต้องรับรู้ว่ามีข้อผิดพลาดใดๆเกิดขึ้นบ้าง หากมี error เกิดขึ้นเราควรจะจัดการในฟังก์ชันก่อนหน้า เช่น ในบรรทัดที่14 เมื่อ findById ไม่สำเร็จเราควรจัดการ error ในฟังก์ชัน getUser ไม่ต้องเรียก getCurrentGravatar พร้อมส่ง error ไปเฉกเช่นตัวอย่างข้างบน

เราจะทำตามสัญญา…

จั่วหัวแบบนี้ไม่ได้เกี่ยวอะไรกับการเมืองนะครับ แต่เรากำลังจะพูดถึงสิ่งที่เรียกว่า Promise ใน JavaScript ก่อนที่เราจะทำความเข้าใจว่าคืออะไร ลองดูโค๊ดตัวอย่างก่อนครับ

const doAsync = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if(Math.random() >= 0.5) resolve('BabelCoder!')
      else reject(new Error('Less than 0.5!'))
    }, 2000)
  })
}

doAsync().then((text) => {
  console.log(text)
}).catch((error) => {
  console.error(error.message)
})

จุดเริ่มต้นของโปรแกรมคือการเรียก doAsync ในบรรทัดที่10 ที่มีการทำงานเริ่มตั้งแต่บรรทัดที่2 สังเกตบรรทัดที่2นะครับ เรา new Promise ขึ้นมา นั่นหมายความว่า Promise ของเราเป็นออบเจ็กต์ที่รับพารามิเตอร์ตัวหนึ่ง เพียงแต่พารามิเตอร์นั้นเป็นฟังก์ชันในคราบน้องคอลลี่คือ (resolve, reject) => {...}

การทำงานของ Promise นั้นไม่มีอะไรมาก เพียงแค่ส่ง resolve และ reject เข้ามาในฟังก์ชัน ส่วนที่เหลือเป็นหน้าที่ของโปรแกรมเมอร์แล้วครับว่าจะจัดการยังไงต่อ ผมจำลองสถานการณ์ที่ยาวนานด้วยการให้รอ2วินาทีผ่าน setTimeout เมื่อครบเวลาโค๊ดในบรรทัดที่4จะเริ่มทำงาน เอาหละถึงเวลาชำแหละ resolve และ reject แล้ว

resolve เป็นการบอกว่าโค๊ด Asynchronous ของเราทำงานเสร็จสิ้นไร้ปัญหาใดๆซึ่งตรงกันข้ามกับ reject ที่เป็นการแจ้งกลับว่าการทำงานนั้นมีข้อผิดพลาด ย้อนกลับไปที่ตัวอย่างครับ ผมสุ่มตัวเลขผ่านฟังก์ชัน random โดยกำหนดว่าหากตัวเลขที่ได้นั้นมากกว่าหรือเท่ากับ 0.5 ถือว่าทำงานสำเร็จจึงครอบผลลัพธ์สมมติของการทำงานคือ BabelCoder!กลับไปผ่าน resolve ทำนองกลับกันหากผลลัพธ์ที่ได้น้อยกว่า0.5ถือว่าล้มเหลวจึง reject พร้อมเหตุผลว่า Less than 0.5! กลับไป

แล้วยังไงต่อ? เราคงไม่ resolve หรือ reject เล่นๆให้เปลืองบรรทัดกันจริงไหม หากแต่จะนำมาใช้เพื่อบอกว่าเมื่อได้ผลลัพธ์แล้วจะทำยังไงต่อ อาศัย then และ catch เราจะได้ว่า หาก resolve หรือทำงานสำเร็จจะทำ then ต่อ ในทางกลับกันจะ catch เมื่อ reject หรือเมื่อมี Error และทำงานไม่สำเร็จ จึงสรุปได้ว่าโค๊ดตัวอย่างของเราจะพิมพ์ BabelCoder! ออกทางหน้าจอเมื่อตัวเลขจากการสุ่มมากกว่าหรือเท่ากับ0.5 ไม่เช่นนั้นจะพิมพ์ Less than 0.5! ออกหน้าจอ

ใช้ Promise แก้ Callback Hell

ถึงเวลาแก้ปัญหาแล้ว มาเปลี่ยนโค๊ดอัพเดท avatar ของเราโดยใช้ Promise กันเถอะ!

const userId = 13

const updateAvatar = (avatar) => {
  return new Promise((resolve, reject) => {
    User.update(userId, avatar, (error, user) => {
      if(error) reject(error)
      else resolve(user)
    })
  })
}


const getCurrentGravatar = (profile) => {
  return new Promise((resolve, reject) => {
    fetch(`http://www.gravatar.com/avatar/${profile.email}`, (error, avatar) => {
      if(error) reject(error)
      else resolve(avatar)
    })
  })
}

const getUser = (userId) => {
  return new Promise((resolve, reject) => {
    User.findById(userId, (error, profile) => {
      if(error) reject(error)
      else resolve(profile)
    })
  })
}

getUser(userId).then((profile) => {
  return getCurrentGravatar(profile)
}).then((avatar) => {
  return updateAvatar(avatar)
}).then((user) => {
  return doXXX(user)
}).catch((error) => {
  console.error(error.message)
})

เห็นโค๊ดแล้วแทบอุทาน นี่หรือเมืองพุทธ นี่มันแทบจะยาวพอๆกับชื่อเต็มกรุงเทพฯแล้วนะ ถึงตรงนี้บางคนอาจรู้สึกว่า ฉันยอมกดแท็บเยอะๆต่อไปจะดีกว่า อย่าพึ่งคิดเช่นนั้นครับ ลองฟังคำอธิบายก่อน

เริ่มกันที่บรรทัดที่31เลย ผมมั่นใจว่าแม้ไม่อธิบายใดๆคุณยังสามารถเข้าใจโค๊ดนี้ได้ด้วยตัวคุณเอง ในบรรทัดที่ 31-39 ผมหาผู้ใช้ระบบที่มีไอดีเป็น13 หากค้นเจอให้หารูปปัจจุบัน เช่นเดียวกันหากพบรูปให้ทำการอัพเดท ทุกอย่างอยู่ภายใต้ประโยค ถ้า...แล้ว(then) เสมอ หากเกิดข้อผิดพลาดจากการ reject โค๊ดภายใต้ catch เท่านั้นที่จะดักจับและทำงาน เข้าใจได้ง่ายและใช้เพียงแท็บเดียวใช่ไหมครับ นั่นคือพลานุภาพแห่ง Promise!

ย้อนกลับไปดูเรื่องน่าปวดหัวบรรทัดที่ 3-29 นิดนึง พบว่าแต่ละฟังก์ชันแม้จะอ่านแล้วเข้าใจง่าย แต่ก็อุดมไปด้วยแก๊งค์ resolve และ reject หากเราเปลี่ยนจากการเขียนเองบางจุดไปใช้ Library ที่สนับสนุนการทำงานกับ Promise ทุกอย่างจะง่ายขึ้นครับ เช่น เปลี่ยน fetch ที่เราเขียนเองไปใช้ fetch และเปลี่ยน findById ที่เขียนเองไปใช้ Mongoose จะได้โค๊ดใหม่ที่สั้นกว่าเดิมดังนี้

const userId = 13

const updateAvatar = (avatar) => {
  return User.update(userId, avatar)
}

const getCurrentGravatar = (profile) => {
  return fetch(`http://www.gravatar.com/avatar/${profile.email}`)
}

const getUser = (userId) => {
  return User.findById(userId)
}

getUser(userId).then((profile) => {
  return getCurrentGravatar(profile)
}).then((avatar) => {
  return updateAvatar(avatar)
}).then((user) => {
  return doXXX(user)
}).catch((error) => {
  console.error(error.message)
})

ย้อนกลับไปดูกันครับว่าโค๊ดชุดปัจจุบันของเราแก้ปัญหาอะไรไปแล้วบ้าง

  • กำจัด ความหม่นหมองของน้องคอลลี่ ด้วยการลดจำนวนแท็บที่ต้องกดไป
  • ฟังก์ชันเป็นเอกเทศ ทุกครั้งที่เราเรียก getCurrentGravatar จะไม่ทำการ updateAvatar เองอีกต่อไป
  • ไม่มีการโยน Error ข้ามไปมาระหว่างฟังก์ชันเฉกเช่นที่ทำในตัวอย่างแรก

เนื่องจากโค๊ดของเราเป็นลักษณะเฉพาะ แต่ละฟังก์ชันแยกย่อยก็มีโค๊ดแค่บรรทัดเดียว เราจึงควรรวมโค๊ดทั้งหมดเป็นฟังก์ชันเดียว เพื่อประหยัดการกวาดสายตาหาว่าแต่ละฟังก์ชันทำอะไร ดังนี้

const updateLatestAvatar = (userId) => {
  return User.findById(userId).then((profile) => {
    return fetch(`http://www.gravatar.com/avatar/${profile.email}`)
  }).then((avatar) => {
    return User.update(userId, avatar)
  }).then((user) => {
    return doXXX(user)
  }).catch((error) => {
    console.error(error.message)
  })
}

updateLatestAvatar(13)

ถึงเวลาพระเอกของเรื่องแล้ว

การแก้ปัญหา Callback Hell น่าจะจบลงที่ Promise หากเพียงแต่เรายังมีวิธีที่ทำให้โค๊ดของเราดูคล้ายโค๊ดแบบ Synchronous มากขึ้น เราจะใช้ Async/Await ใน ES7 ดังนี้

async function updateLatestAvatar(userId) {
  try {
    const profile = await User.findById(userId)
    const avatar  = await fetch(`http://www.gravatar.com/avatar/${profile.email}`)
    const user    = await User.update(userId, avatar)
    doXXX(user)
  } catch(error) {
    console.error(error.message)
  }
}

updateLatestAvatar(13)

เมื่อเรากำจัด then ออกไปได้จะรู้สึกทันทีว่าโค๊ด Asynchronous ดูอ่านง่ายขึ้นเฉกเช่นเดียวกับการอ่านโค๊ดจากบนลงล่างในภาษา C/C++ สิ่งที่เราต้องทำมีดังนี้

  • ใช้ try..catch เพื่อดักจับ Error แทน catch ใน then..catch ของ Promise
  • ตรงไหนที่เป็นโค๊ดแบบ Asynchronous เราไม่ใช้ then แต่ใส่ await เข้าไปข้างหน้าในความหมายที่ว่า อ๊ะ... รอเค้าเสร็จก่อนนะ แทน
  • ฟังก์ชันที่จะใช้ Await ให้ใส่ async เข้าไปหน้า keyword function
  • ต้องเข้าใจเสมอว่า Promise ไม่ได้หายไปไหน อย่าลืมว่า findById, fetch หรือ update ล้วนคืนค่าเป็น Promise ทั้งสิ้น
  • ข้อควรจำคือ Async/Await ไม่ได้ทำให้โค๊ดของคุณเปลี่ยนจาก Asynchronous เป็น Synchronous แต่อย่างใด

Async/Await นั้นเป็นของใหม่ใน ES7 ที่ยังไม่มาในตอนนี้ (ปัจจุบันเป็น ES2015) หากคุณต้องการใช้ผมแนะนำให้ใช้ผ่าน Babel เช่นเดียวกันเพื่อให้คุณสามารถใช้ Promise ได้ในทุกที่คือทั้งทุก Browser และทั้งใน Node.js ผมขอแนะนำให้คุณใช้ Bluebird แล้วคุณจะค้นพบว่า Asynchronous code ไม่ยากอีกต่อไป(ซะที่ไหนหละ ปัดโถ่!)

เอกสารอ้างอิง

petkaantonov. API Reference | bluebird. Retrieved April, 17, 2016, from http://bluebirdjs.com/docs/api-reference.html

Joe Zimmerman (2015). Simplifying Asynchronous Coding with ES7 Async Functions. Retrieved April, 17, 2016, from http://www.sitepoint.com/simplifying-asynchronous-coding-es7-async-functions/


แสดงความคิดเห็นของคุณ


Nuttawut Singhabut10 เดือนที่ผ่านมา

มาจาก บทความสอนเขียน React ครับ ^ ^ บทความอ่านเข้าใจง่ายดีครับ ผมอ่านทุกลิ้งค์ที่ Reference เลย

ข้อความตอบกลับ
Nuttavut Thongjor10 เดือนที่ผ่านมา

ขอบคุณครับ 😃


Nuttavut Thongjorปีที่แล้ว

@saknarak ขอบคุณมากครับ 😃


saknarakปีที่แล้ว

แสดงความคิดเห็นครับ ฟังก์ชั่น updateLatestAvatar ควร return promise เพื่อให้รู้ว่า fulfill หรือ reject ได้ เวลานำไปเรียกใช้

const updateLatestAvatar = (userId) => { User.findById(userId).then((profile) => {

เปลี่ยนเป็น

const updateLatestAvatar = (userId) => { return User.findById(userId).then((profile) => {

ปล. ช่อง comment น่าจะขึ้นบรรทัดใหม่ตามที่พิมพ์ หรือรับโค้ด markdown ก็ยังดี จะได้อ่านง่ายขึ้น