Angular 22 เปิดตัวฟีเจอร์ Resource แต่การเขียนข้อมูลยังต้องพึ่งเครื่องมือเสริม
Angular 22 มาพร้อม resource() และ httpResource() สำหรับการดึงข้อมูล แต่การเขียนข้อมูลยังต้องอาศัยไลบรารีอย่าง @ngsignal/mutation ที่รองรับเวอร์ชัน 0.6.0 แล้ว
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Angular 22 เปิดตัว resource() และ httpResource() สำหรับการดึงข้อมูลอย่างเป็นทางการ แต่ไม่ได้ออกแบบมาสำหรับการเขียนข้อมูล
- @ngsignal/mutation คือไลบรารีทางเลือกสำหรับจัดการสถานะการเขียนข้อมูลด้วย Signal โดยไม่ต้องมี Store หรือ Cache
- ไลบรารีนี้รองรับระบบ Concurrency, การจัดการ Error, Lifecycle และ SSR โดยไม่ต้องพึ่ง RxJS เป็นแกนหลัก
- ปัจจุบันเวอร์ชัน 0.6.0 รองรับ Angular เวอร์ชัน 21 และ 22 พร้อมระบบจัดการคิวคำขอและสถานะที่ชัดเจน
ระบบ Reactive ของ Angular พัฒนาไปอีกขั้นเมื่อฟังก์ชัน resource() และ httpResource() กลายเป็นฟีเจอร์เสถียรใน Angular 22 การดึงข้อมูลจึงกลายเป็นเรื่องง่าย เพียงระบุสิ่งทีพึ่งพาและอ่านค่า Signal ที่ได้โดยปล่อยให้ Angular จัดการเบื้องหลังทั้งหมด แต่ความท้าทายคือ Angular จงใจไม่ใช้ resource() สำหรับการเขียนข้อมูล ทำให้เกิดคำถามว่า API สำหรับการเขียนข้อมูลที่ใช้งานร่วมกับ Signal ควรมีหน้าตาอย่างไร
นี่คือปัญหาที่ไลบรารี @ngsignal/mutation เข้ามาแก้ไข โดยออกแบบ API ให้สะท้อนโครงสร้างตระกูล resource ของ Angular เพื่อให้การเขียนข้อมูลมีความรู้สึกเป็นธรรมชาติแบบเดียวกับ Angular resources โดยไม่ต้องสร้าง Data Layer ใหม่ สิ่งที่ไลบรารีนี้มอบให้ไม่ใช่โค้ดจำนวนมาก แต่เป็นสัญญาพฤติกรรมสำหรับการเขียนข้อมูล ทั้งสถานะ ข้อผิดพลาด วงจรชีวิต SSR และการทำงานร่วมกันพร้อมๆ กัน
ในขณะที่ API สำหรับการอ่านข้อมูลถูกออกแบบมาเพื่อการดึงข้อมูลและคำแนะนำของ httpResource ก็แนะนำให้ใช้ HttpClient โดยตรงสำหรับคำขอประเภท POST และ PUT ตามบันทึกข้อตกลงของ Resource RFC เหตุผลสำคัญคือการยกเลิกคำขอมีความหมายต่างกันอย่างสิ้นเชิงระหว่างการอ่านและการเขียน การอ่านข้อมูลที่เก่ากว่าสามารถละทิ้งได้เมื่อมีคำขอใหม่เกิดขึ้น แต่การเขียนข้อมูลอาจส่งผลให้เซิร์ฟเวอร์เปลี่ยนแปลงไปแล้ว ตัวอย่างเช่น คำขอ POST /orders หากเซิร์ฟเวอร์สร้างคำสั่งซื้อไปแล้วแต่เบราว์เซอร์หยุดรอการตอบกลับ คุณสามารถยกเลิกคำขอบนฝั่งไคลเอนต์ได้ แต่ไม่สามารถยกเลิกสิ่งที่เซิร์ฟเวอร์ทำไปแล้วได้
"This result is stale" does not mean "this write must be cancelled."
Erwan Raulo
ไลบรารี @ngsignal/mutation จึงเลือกแนวทางที่แตกต่างโดยไม่มี Store ไม่มี Cache ไม่มี Provider และไม่มี RxJS เป็นแกนหลัก มีเพียงพริมทีฟขนาดเล็กที่ทำงานกับ Signal สำหรับการเขียนข้อมูล การใช้งานทำได้ง่ายผ่านฟังก์ชัน mutation() ที่แปลงอินพุตให้เป็น Promise พร้อมเปิดเผย Read-only signals สำหรับสถานะต่างๆ เช่น isPending() และ isSuccess() ให้เทมเพลตอ่านค่าได้โดยตรง
ในมุมมองของการพัฒนาเว็บแอปพลิเคชันสมัยใหม่ การจัดการ State Machine สำหรับการส่งข้อมูล (Mutations) มักเป็นจุดที่ซับซ้อนที่สุดเนื่องจากต้องคำนึงถึงสถานะระหว่างรอ การยกเลิกคำขอ และการชนกันของข้อมูล (Concurrency) การที่นักพัฒนาพยายามสร้างโค้ดจัดการสิ่งเหล่านี้ขึ้นมาเองในทุกโปรเจกต์มักนำไปสู่ปัญหาความซ้ำซ้อน การใช้ไลบรารีที่มีขอบเขตชัดเจนและพึ่งพา Signal โดยตรงจึงช่วยลดความบวมของโค้ดและรักษาความสอดคล้องกับสถาปัตยกรรมหลักของ Angular ได้เป็นอย่างดี
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
นอกจากนี้ ฟังก์ชัน httpMigration() ยังช่วยขยายความสามารถในการจัดการคำขอ HTTP คล้ายกับ httpResource() รองรับการอัปโหลดไฟล์พร้อมแถบแสดงความคืบหน้า ส่วนหัวของการตอบกลับ และการดาวน์โหลดไฟล์ PDF ที่สร้างจากคำขอ POST การเรียกใช้งาน mutate() ครั้งใหม่จะไม่ยกเลิกคำขอก่อนหน้า เว้นแต่จะเรียก reset() หรือทำลาย context เพื่อป้องกันไม่ให้ผลลัพธ์ที่เก่ากว่ามาทับซ้อนข้อมูล พร้อมทั้งมีระบบจัดการคิว (Concurrency: 'queue') ที่ช่วยให้คำขอถูกส่งทีละรายการตามลำดับที่ไคลเอนต์ส่งไป
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น