สิ่งที่อยากรู้ก่อนย้ายโค้ด 50K บรรทัดไปใช้ React Server Components

 (mux.com)
1 คะแนน โดย GN⁺ 2023-09-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความเกี่ยวกับประสบการณ์และบทเรียนที่ผู้เขียนได้พบระหว่างย้ายโค้ด 50,000 บรรทัดไปใช้ React Server Components (RSCs)
  • RSCs คือ React component ที่ทำงานบนเซิร์ฟเวอร์แทนไคลเอนต์ และมอบข้อได้เปรียบสำคัญ 2 ประการเหนือการเรนเดอร์ฝั่งเซิร์ฟเวอร์ (SSR)
    • ประการแรก RSCs ช่วยให้นักพัฒนาระบุได้ว่าโค้ดจะทำงานที่ใด ทำให้ขนาดบันเดิลเล็กลงและลดงานระหว่าง hydration
    • ประการที่สอง server component สามารถดึงข้อมูลได้โดยตรงภายในคอมโพเนนต์และสตรีมไปยังไคลเอนต์ ทำให้การดึงข้อมูลใน React ง่ายและมีประสิทธิภาพมากขึ้น
  • อย่างไรก็ตาม การใช้ RSCs ก็มีข้อจำกัดบางประการ เช่น CSS-in-JS ใช้งานใน server component ไม่ได้, React Context เข้าถึงได้เฉพาะใน client component เท่านั้น และความซับซ้อนในการจัดการตำแหน่งที่โค้ดทำงานอาจเป็นความท้าทาย
  • ผู้เขียนเสนอแนวทาง 3 ขั้นตอนสำหรับการนำ RSCs มาใช้แบบค่อยเป็นค่อยไป:
    • เพิ่ม directive "use client" ที่ root ของแอป
    • ย้าย directive ลงไปยังตำแหน่งที่ต่ำที่สุดเท่าที่เป็นไปได้ใน rendering tree
    • นำ pattern ขั้นสูงมาใช้เมื่อเกิดปัญหาด้านประสิทธิภาพ
  • แม้จะมีความซับซ้อนเพิ่มขึ้น แต่ผู้เขียนสรุปว่าข้อดีของ RSCs เช่น ขนาดบันเดิลที่เล็กลง การทำงานที่เร็วขึ้น และรูปแบบการโหลดข้อมูลขั้นสูง อาจคุ้มค่ากับต้นทุน หากทีมให้ความสำคัญกับประโยชน์ด้านประสิทธิภาพ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-03
ความคิดเห็นจาก Hacker News
  • บทความกล่าวถึงการย้ายโค้ด 50K บรรทัดไปใช้ React Server Components (RSCs)
  • ผู้ใช้บางคนกล่าวถึงความเร็วและความเรียบง่ายของการเรนเดอร์ฝั่งเซิร์ฟเวอร์ โดยชี้ว่าฝั่งไคลเอนต์จะได้รับ HTML ที่สามารถแสดงผลได้ทันที
  • มีข้อเสนอว่าการพิจารณาใช้เฟรมเวิร์กแบบฟูลสแตกหรือเว็บเฟรมเวิร์กแบบคลาสสิก เช่น Rails, Django, Laravel แทน RSCs อาจเป็นทางออกที่เร็วกว่าและขยายระบบได้ดีกว่า
  • ผู้ใช้บางคนแสดงความกังวลต่อความซับซ้อนของเฟรมเวิร์กสมัยใหม่ โดยกล่าวถึงกระบวนการ build และ compile จำนวนมากที่จำเป็นแม้สำหรับงานง่าย ๆ
  • ผู้ใช้ได้แชร์ประสบการณ์ส่วนตัวกับ next.js และการตั้งค่าไดเรกทอรี app แบบใหม่ โดยเน้นถึงความยากในการทำความเข้าใจว่างานเกิดขึ้นที่ไหน (เซิร์ฟเวอร์หรือไคลเอนต์) และปัญหากับไลบรารี React เดิมที่ตั้งสมมติฐานว่าทำงานฝั่งไคลเอนต์
  • ผู้ใช้บางคนชี้ให้เห็นบั๊กและจุดที่ยังขรุขระในพาราไดม์ app directory แบบใหม่ของ next.js รวมถึงปัญหาที่เกี่ยวข้องกับ dynamic routes และ parallel routes
  • ผู้ใช้รายหนึ่งกล่าวถึงความคล้ายกันระหว่าง PHP และ JavaScript โดยชี้ว่า JavaScript ได้พัฒนาไปจนให้ความสามารถฝั่งเซิร์ฟเวอร์ที่คล้ายกัน แม้จะมีตัวย่อมากกว่าและเส้นโค้งการเรียนรู้ที่ชันกว่า
  • ผู้ใช้บางคนตั้งคำถามถึงความจำเป็นของการใช้ React กับงานที่อาจแก้ได้ด้วยเครื่องมือที่ง่ายกว่า เช่น static site generator หรือ CMS ที่มี caching
  • มีอารมณ์โหยหายุคที่เซิร์ฟเวอร์เรนเดอร์ทุกอย่าง และ CSS กับ JavaScript เข้ามาเสริมหน้าเว็บหลังการเรนเดอร์
  • ผู้ใช้บางคนแสดงความเห็นว่า React กำลังซับซ้อนขึ้นเพื่อไล่ตามทางเลือกสมัยใหม่ที่ง่ายและเร็วกว่า
  • มีการถกเถียงเรื่องการใช้ React เพื่อเรนเดอร์ HTML จากฝั่งแบ็กเอนด์ โดยบางคนตั้งคำถามถึงความจำเป็น ขณะที่อีกบางคนปกป้องข้อดีของมันเหนือวิธีที่เซิร์ฟเวอร์ส่งผลลัพธ์แบบดั้งเดิม