React-Redux บันทึกเราควรเอา Business logic ไว้ส่วนไหนดี และ thunk middleware คืออะไร
Business logic ควรไว้ที่ไหน และ Redux Thunk ที่ใช้อยู่มีประโยชน์อย่างไร
เป็นคำถามที่เจอได้บ่อยว่า เราควรเอา Business logic ไว้ที่ไหนดี ซึ่งจากประสบการณ์ส่วนตัว ขอสรุปสั้นๆ ดังนี้
Action creator = ถ้าเราต้องการทำ Business logic ที่ ทำงานแบบ Async ทางเลือกที่เหมาะสม ณ เวลานี้ คือ ที่นี่
Reducer = ถ้าเป็นงานแบบง่ายๆ Synchronous ก็คงต้องเป็นที่นี่
Smart component or container component = ก็เป็นตัวเลือกนึง ที่ผมเคยเห็นมา
ดูข้อมูลเพิ่มเติม ที่นี่ ของน้องไทปังสรุปไว้
แล้วที่ไหนเหมาะสมที่สุด?
ผมบังเอิญไปเจอ medium ที่นี่สนใจเลยทีเดียว เขาสรุปปัญหา ข้อดี ข้อเสีย ได้ชัดเจน และแนะนำ Solution ที่เหมาะสมที่สุด ณ เวลานี้เอาไว้ด้วย
ซึ่งเขาก็ได้แนะนำ Approach ที่สามารถจัดการปัญหา ไว้ดังนี้
- reators
- reducers
- thunks
- sagas
- epics
- effects
- custom middleware
- redux-logic — a new approach
แล้วผมเลือกใช้อะไร?
ปัจจุบันผมใช้ redux-thunk เป็น middleware ของโปรเจค (ใช้มาแต่แรกเริ่มโปรเจคแล้ว) ถ้าถามถึงว่าทำไม ต้องใช้ thunk เป็น middleware ก็คงตอบได้ว่า ผมทำตาม tutorial ในยุคแรกๆ ที่เขาสอน react แต่ถ้าหากมีโปรเจคใหม่ให้ทำ ก็คงมาพิจารณาอีกทีว่าจะใช้ตัวไหนในการจัดการ

ภาพข้างบน คือ อธิบายว่า thunk ทำหน้าที่อะไรใน Redux มัน คือ middleware ดีๆนี่แหละ ทำหน้าที่เป็นคนกลาง ระหว่าง action <> reducer
ทำไมต้องมี middleware?
เนื่องจากว่า Action Creator ของเรานั้น ทำงานได้ทั้งรูปแบบ Asynchronous และ Synchronous ก่อนที่จะ dispatch action ไปยัง Reducer เพื่อสร้าง new state
คำถาม? หากเราต้องมี Action ที่ทำงานแบบ Async แล้วภายในมี Promise หล่ะ จะเกิดปัญหาอะไรตามมา คำตอบ คือ Reducer ไม่สามารถ Resolve future object เพื่อสร้าง new state ได้ ทันที
จึงเป็นที่มาว่า เราต้องการคนกลาง ทำหน้าที่ resolve object promise นั่นก่อน dispatch action ไปยัง Reducer
Redux-thunk is the most popular middleware used to handle asynchronous actions in Redux.
ดูตัวอย่างได้ที่นี่
จัดการ middleware อย่างชาญฉลาดด้วยการใช้ของชาวบ้าน!
ท้ายสุดแล้วนั้น middleware หรือ สถานที่ที่ควรเก็บ Business logic ตัวไหนเหมาะสมนั้น ก็ต้องขึ้นอยู่กับสภาพแวดล้อมนั้นๆ การสื่อสารในทีมก็สำคัญ เพราะไม่ว่าเราจะออกแบบสถาปัตยกรรมดีเท่าใด แต่เมื่อถึงเวลาต้อง maintenance ทีมไม่สามารถ คาดเดาที่ๆเก็บ Business logic ได้ นั่นแสดงว่า เราสื่อสารกันไม่ดีเพียงพอแล้วหล่ะครับ
