React Compiler 1.0: ลบ useMemo ได้เมื่อไร และเมื่อไรห้ามลบ

ก่อนเพิ่มสิ่งนี้เข้า stack ลองเขียนให้ได้หนึ่งบรรทัดว่าเราหวังให้ชีวิตดีขึ้นตรงไหน เมื่อ React Compiler 1.0 เป็น stable และทำ automatic memoization ที่ build time พร้อม lint rules สิ่งที่ควรทำต่อไม่ใช่ขยายทันที แต่คือ เปิด compiler แบบ incremental, เก็บ profiler baseline แล้วลบ manual memo ทีละกลุ่ม

ก่อนลงมือกับ React Compiler 1.0 ต้องแยกสิ่งที่ยืนยันแล้วออกจากสิ่งที่เราคาด

รายละเอียดของ “React Compiler 1.0” ควรตรวจกลับไปที่ React Compiler v1.0 โดยตรง โดยเฉพาะถ้อยคำ สเปก และขอบเขตที่ประกาศไว้ ส่วนข้อจำกัดของระบบ งบ และความเสี่ยงที่รับได้ยังเป็นคำถามของคนใช้งาน

ผลของ “React Compiler 1.0” ไม่ได้หยุดที่ syntax หรือเลขเวอร์ชัน แต่วิ่งต่อไปถึง dependency, CI, observability และคนที่ต้องรับช่วงระบบในคืนที่มันมีปัญหา

วิธีลดความเสี่ยงของ React Compiler 1.0 คือทำให้การเปลี่ยนครั้งแรกเล็กและถอยได้

การลอง “React Compiler 1.0” ควรมีเวลาเริ่ม–จบ เก็บสภาพเดิมไว้เทียบ และเขียนทางถอยก่อนลงมือ ขอบเขตแบบนี้ช่วยให้ตอบได้ว่าผลที่เห็นมาจากสิ่งที่เปลี่ยนจริง

หลักฐานสำหรับตัดสินใจเรื่อง React Compiler 1.0 ควรเป็น diff ที่รีวิวได้ test ที่จับ behavior เดิม และตัวเลขก่อน–หลังจาก workload เดียวกัน

## ด้านที่มักไม่ถูกพูดถึง

compiler ช่วยงานซ้ำ แต่ memoization ที่เป็น semantic contract หรือแก้ identity กับ library ภายนอกยังต้องคิดเอง นี่ไม่ใช่เหตุผลให้ปฏิเสธของใหม่ แต่เป็นเหตุผลให้แยก “ทำได้แล้ว” ออกจาก “พร้อมสำหรับงานของเราแล้ว”

จุดชั่งใจของเรื่องนี้คือการได้ความสามารถใหม่โดยไม่สร้าง migration surface ใหญ่เกินประโยชน์ ถ้า เปิด compiler แบบ incremental, เก็บ profiler baseline แล้วลบ manual memo ทีละกลุ่ม ทำแยกเป็นขอบเขตเล็กไม่ได้ นั่นเป็นสัญญาณว่าควรออกแบบ boundary ก่อนอัปเกรด

สุดท้าย React Compiler 1.0 ต้องตอบด้วยผลจากการใช้ ไม่ใช่ความใหม่

หลังทดลอง React Compiler 1.0 เราควรตอบได้ว่าปัญหาเดิมดีขึ้นหรือไม่ ภาระใหม่คืออะไร และถ้าขยายผลแล้วใครจะดูแล ถ้ายังตอบไม่ได้ การหยุดไว้ก่อนก็เป็นผลลัพธ์ที่ดี