TanStack เปิดตัว Table v9 เวอร์ชัน beta ซึ่งเป็นไลบรารี data-grid ที่ช่วยให้นักพัฒนาเลือกใช้งานเฉพาะฟีเจอร์ที่จำเป็นเท่านั้น ขนาดของ bundle จะลดลงเหลือประมาณ 5 KB และปัญหาความล่าช้าของ interaction-to-next-paint (INP) ที่ทำให้การเรียงลำดับ (sorting) หรือการกรอง (filtering) รู้สึกหน่วงก็จะหายไป

ทำไมการเปลี่ยนแปลงนี้จึงสำคัญ

ใน v8 ไลบรารีจะส่งตรรกะ (logic) ของ grid มาให้ทั้งหมด ไม่ว่าจะเป็นการเรียงลำดับ (sorting), การกรอง (filtering), การแบ่งหน้า (pagination), การเลือกแถว (row selection) หรือการจัดกลุ่ม (grouping) แม้ว่าโปรเจกต์นั้นจะไม่ได้ใช้งานฟีเจอร์เหล่านั้นเลยก็ตาม โค้ดส่วนเกินเหล่านี้จะทำงานบน main thread ซึ่งทำให้ขนาด bundle ใหญ่ขึ้นและเพิ่มความหน่วง (latency) ให้กับการกระทำของผู้ใช้ สำหรับ dashboard ที่ต้องการตารางที่รวดเร็วและตอบสนองไว ความล่าช้าเพียงไม่กี่มิลลิวินาทีก็สามารถทำให้คะแนน INP ตกลงไปอยู่ในเกณฑ์ที่แย่ได้

สิ่งที่ v9 ทำแตกต่างออกไป

  • Opt-in feature modules – เลือกนำเข้าเฉพาะโมดูลที่ใช้งานจริง หากคุณไม่ใช้การเรียงลำดับ (sorting) โค้ดสำหรับการเรียงลำดับก็จะไม่ถูกรวมเข้าไปใน bundle
  • TanStack Store integration – จัดการ state ด้วย store ที่มีความละเอียดสูง (fine-grained) ทำให้การอัปเดตเพียงแถวเดียวไม่ไปกระตุ้นให้เกิดการ re-render ทั้งแถบตัวกรอง (filter bar) หรือ UI ส่วนอื่นๆ ที่ไม่เกี่ยวข้อง
  • Reduced memory footprint – ลดการใช้หน่วยความจำ โดยการลดจำนวน object และ array ลง ช่วยลดภาระของ JavaScript heap ในระหว่างการใช้งานที่ยาวนาน

การเปลี่ยนแปลงเหล่านี้ส่งผลให้ขนาดการดาวน์โหลดเล็กลง (ไลบรารีอาจมีขนาดใกล้เคียง 5 KB สำหรับรายการแบบง่าย) และทำให้การโต้ตอบราบรื่นยิ่งขึ้นเมื่อ grid มีการทำงานหนัก

ใครจะได้รับประโยชน์

  • Frontend teams ที่สร้างเครื่องมือภายใน (internal tools), แผงควบคุม (admin panels) หรือ SaaS dashboards ซึ่งตารางเป็นองค์ประกอบ UI หลัก
  • Performance-focused sites ที่ให้ความสำคัญกับการตรวจสอบ Core Web Vitals โดยค่า INP ที่ต่ำลงจะช่วยปรับปรุงตัวชี้วัดนี้โดยตรง

สิ่งที่ v9 ไม่ได้แก้ไข

การปรับปรุงเหล่านี้มุ่งเน้นไปที่โค้ดที่คุณควบคุมได้เท่านั้น มันจะไม่ช่วยให้หน้าเว็บที่ดึงข้อมูล JSON ขนาดมหึมาเร็วขึ้นอย่างน่าอัศจรรย์ และไม่สามารถชดเชยภาระของสคริปต์จากบุคคลที่สาม (third-party script) ที่มีขนาดใหญ่ได้ ชุดข้อมูลขนาดใหญ่ยังคงต้องการการแบ่งหน้า (pagination) ที่เหมาะสม และความหน่วงของเครือข่าย (network latency) ก็ยังคงเป็นปัญหาแยกต่างหาก

แนวทางการย้ายระบบ (migration) ที่นำไปใช้ได้จริง

  1. ระบุตารางที่ทำงานหนักที่สุด – มองหารายการคำสั่งซื้อ, grid สินค้าคงคลัง หรือมุมมอง CRM ที่เริ่มแสดงอาการหน่วงอย่างเห็นได้ชัด
  2. บันทึกค่าพื้นฐาน (baseline metrics) – บันทึกค่า INP และระยะเวลาของ long-task ในหน้าเหล่านั้นก่อนที่จะมีการเปลี่ยนแปลงใดๆ
  3. ทยอยย้ายทีละ grid – เปลี่ยนการ import จาก v8 เป็นชุดโมดูลของ v9 โดยเปิดใช้งานเฉพาะฟีเจอร์ที่หน้าจอนั้นใช้งานจริงเท่านั้น
  4. หลีกเลี่ยงการใช้ bundle stockFeatures แบบครอบจักรวาล – การดึงชุดฟีเจอร์เริ่มต้นมาทั้งหมดจะทำให้จุดประสงค์ในการประหยัดขนาดไฟล์เสียไป
  5. ทดสอบการโต้ตอบอีกครั้ง – วัดผลการเรียงลำดับ, การกรอง และการเลือกอีกครั้ง เพื่อยืนยันประสิทธิภาพที่เพิ่มขึ้น

ข้อควรระวัง: ไม่ใช่ยาสารพัดนึก

นักพัฒนาบางคนอาจคาดหวังว่า v9 จะแก้ปัญหา UI ที่อืดอาดได้ทุกอย่าง แต่ในความเป็นจริง ประสิทธิภาพที่เพิ่มขึ้นของไลบรารีนั้นขึ้นอยู่กับปริมาณโค้ดที่คุณสามารถตัดทอนออกได้ หากคอขวด (bottleneck) ของตารางคือจำนวนแถวที่มากเกินไปหรือ API ของเซิร์ฟเวอร์ที่ไม่มีประสิทธิภาพ การลดขนาด bundle ก็จะมีผลกระทบเพียงเล็กน้อยเท่านั้น

สิ่งที่ควรติดตามต่อไป

Takeaway: TanStack Table v9 มอบวิธีที่เป็นรูปธรรมในการหยุดเสียทรัพยากรไปกับฟังก์ชันการทำงานของ grid ที่ไม่ได้ใช้งาน ด้วยการนำเข้าเฉพาะโมดูลที่จำเป็นและใช้ store ที่มีความละเอียดสูง คุณสามารถลดขนาด bundle ลงได้หลายกิโลไบต์ และทำให้การโต้ตอบกับตารางรวดเร็วขึ้นอย่างเห็นได้ชัด—ตราบใดที่คุณใช้การอัปเกรดนี้ควบคู่ไปกับกลยุทธ์การจัดการข้อมูลที่เหมาะสม