React 19

 (github.com/facebook)
2 คะแนน โดย GN⁺ 2024-12-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

19.0.0 (5 ธันวาคม 2024)

ฟีเจอร์ใหม่

React
  • Actions: ตอนนี้ startTransition รองรับฟังก์ชันแบบอะซิงก์แล้ว ฟังก์ชันเหล่านี้เรียกว่า "Actions" และจะอัปเดต state ในเบื้องหลังพร้อม commit UI ในครั้งเดียว Actions สามารถทำ side effects เช่นคำขอแบบอะซิงก์ได้ และจะรอให้งานเสร็จก่อนที่ Transition จะจบลง
  • useActionState: ฮุกใหม่ที่ใช้จัดลำดับ Actions ภายใน Transition และเข้าถึง state ได้ รับ initial state และ reducer
  • useOptimistic: ฮุกใหม่สำหรับอัปเดต state ระหว่างที่ Transition กำลังดำเนินอยู่ เมื่อ Transition เสร็จสิ้น state จะถูกอัปเดตเป็นค่าใหม่
  • use: API ใหม่ที่ใช้สำหรับอ่าน resource ระหว่างการเรนเดอร์ รองรับ Promise หรือ Context และหากส่ง Promise มา จะ suspend จนกว่าค่านั้นจะ resolve
  • ใช้ ref เป็น prop: สามารถใช้ ref เป็น prop ได้โดยไม่ต้องใช้ forwardRef
  • การ prewarm sibling ของ Suspense: เมื่อคอมโพเนนต์เกิดการ suspend React จะ commit fallback ของขอบเขต Suspense ที่ใกล้ที่สุดทันที
React DOM Client
  • prop action ของ <form>: Form Actions จะจัดการฟอร์มให้อัตโนมัติและทำงานร่วมกับ useFormStatus โดยจะรีเซ็ตฟอร์มอัตโนมัติเมื่อสำเร็จ
  • รองรับ document metadata: สามารถเรนเดอร์แท็ก metadata ของเอกสารจากคอมโพเนนต์ได้แบบเนทีฟ
  • รองรับ stylesheet: จะแทรก stylesheet เข้าไปใน <head> ของฝั่งไคลเอนต์ก่อนเปิดเผยเนื้อหาภายในขอบเขต Suspense
  • รองรับ async script: สามารถเรนเดอร์สคริปต์แบบอะซิงก์ได้จากที่ใดก็ได้ใน component tree
React DOM Server
  • เพิ่ม API prerender และ prerenderToNodeStream: เป็น API สำหรับการสร้าง static site ซึ่งออกแบบมาให้ทำงานในสภาพแวดล้อมแบบสตรีมมิง เช่น Node.js stream และ web stream
React Server Components
  • ความสามารถของ RSC: directives, server components และ server functions ถูกทำให้เสถียรแล้ว ไลบรารีที่มี server components สามารถตั้งเป้า React 19 เป็น peer dependency ได้แล้ว

การเลิกใช้งานในอนาคต

  • การเข้าถึง element.ref: เลิกใช้การเข้าถึง element.ref โดยแนะนำให้ใช้ element.props.ref แทน
  • react-test-renderer: ใน React 19 นั้น react-test-renderer จะบันทึกคำเตือนการเลิกใช้งาน และเปลี่ยนไปใช้ concurrent rendering สำหรับการใช้งานบนเว็บ

การเปลี่ยนแปลงสำคัญ

React
  • ต้องใช้ JSX transform ใหม่: จำเป็นต้องใช้ JSX transform แบบใหม่เพื่อปรับปรุงขนาด bundle และเพื่อให้ใช้ JSX ได้โดยไม่ต้อง import React
  • ข้อผิดพลาดระหว่างเรนเดอร์จะไม่ถูกโยนซ้ำ: หาก Error Boundary ไม่ได้จับข้อผิดพลาดไว้ ข้อผิดพลาดจะถูกรายงานไปที่ window.reportError
  • ลบ propTypes: การใช้ propTypes จะถูกเพิกเฉยแบบเงียบ ๆ แนะนำให้ย้ายไปใช้ TypeScript
  • ลบ defaultProps ของฟังก์ชัน: สามารถใช้พารามิเตอร์เริ่มต้นของ ES6 แทนได้
  • ลบ string refs: ต้องย้ายการใช้ string refs ไปเป็น ref callback
React DOM
  • ลบ react-dom/test-utils: ย้าย act จาก react-dom/test-utils ไปไว้ใน react ส่วนยูทิลิตีอื่น ๆ ถูกลบออก
  • ลบ ReactDOM.render, ReactDOM.hydrate: ถูกแทนที่ด้วย ReactDOM.createRoot และ ReactDOM.hydrateRoot สำหรับ concurrent rendering

การเปลี่ยนแปลงที่น่าสนใจ

React
  • ใช้ <Context> เป็น provider: สามารถเรนเดอร์ <Context> เป็น provider ได้แทน <Context.Provider>
  • รองรับ custom elements: React 19 ผ่านการทดสอบ custom elements ทั้งหมด
  • การเปลี่ยนแปลงใน StrictMode: useMemo และ useCallback จะนำผลลัพธ์ที่ memoize จากการเรนเดอร์ครั้งแรกกลับมาใช้ซ้ำ
React DOM
  • แสดงความแตกต่างสำหรับ hydration errors: หากเกิดความไม่ตรงกัน React 19 จะบันทึกข้อผิดพลาดเพียงรายการเดียวที่มีรายละเอียดความแตกต่างของเนื้อหาที่ไม่ตรงกัน

การเปลี่ยนแปลงใน TypeScript

  • ห้าม implicit return: ตอนนี้ refs รองรับเฉพาะ cleanup function เท่านั้น การคืนค่าแบบ implicit จะทำให้เกิดข้อผิดพลาด
  • ต้องมีอาร์กิวเมนต์เริ่มต้นของ useRef: ตอนนี้อาร์กิวเมนต์เริ่มต้นเป็นสิ่งจำเป็น
  • การพิมพ์ชนิด ReactElement ที่เข้มงวดขึ้น: ตอนนี้ props ของ React element จะตั้งต้นเป็น unknown แทน any

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

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

 
GN⁺ 2024-12-06
ความคิดเห็นบน Hacker News

  • ผมไม่ค่อยเข้าใจว่าทำไมคนจำนวนมากที่นี่ถึงเกลียด React กันขนาดนี้
    ผมเริ่มอาชีพด้วย Laravel และ JS ล้วน ๆ แต่หลังจากได้ใช้ React การสร้างแอปที่ขยายต่อได้ก็เริ่มรู้สึกเป็นไปได้จริง และงานฟรอนต์เอนด์ก็สนุกขึ้น
    ถึงจะเปลี่ยนบริษัท React ก็กลับมาจับต่อได้ง่าย และด้วยการรองรับ TypeScript กับ ecosystem ขนาดใหญ่ ทำให้รู้สึกว่าสามารถสร้างและขยายแทบทุกอย่างได้ค่อนข้างง่าย
    ผมก็ไม่เข้าใจเหมือนกันว่าทำไมฟีเจอร์ใหม่ ๆ ถึงทำให้ผู้คนกลัวกัน ยังสามารถทำเป็น SPA หรือใช้วิธีแบบเดิมได้อยู่ เหมือนตอน NoSQL DB, Spring Boot หรือ Kotlin ออกมา ถ้าไม่อยากใช้ก็ไม่ต้องใช้
    ผมเข้าใจว่า Jetpack Compose กับ SwiftUI ก็ได้รับแรงบันดาลใจจาก React เหมือนกัน เหมือนเคยเห็นในเอกสาร Android เมื่อก่อน แต่ตอนนี้หาไม่เจอแล้ว
    แต่ผมยังไม่ได้มีประสบการณ์หลายสิบปี จึงไม่รู้ว่าทีมขนาดใหญ่ในยุคก่อน ๆ สนุกแค่ไหนตอนสร้างเว็บแอปใหญ่ ๆ อย่าง Airbnb ด้วย jQuery หรือ JS ล้วน ๆ ตอนนี้แค่จินตนาการว่าจะจัดการ state, การ manipulate DOM และ side effects ด้วย JS ล้วน ๆ อย่างไรก็ยากแล้ว
    สักวันหนึ่งผมอาจจะบ่นเฟรมเวิร์กใหม่ ๆ แล้วพูดว่า React นั้นดีมากก็ได้

    • ผมไม่ค่อยเข้าใจความรู้สึกต่อต้าน React เพราะมักดูเหมือนมาจากคนที่ไม่ได้ใช้งานจริงมากนัก
      เหตุผลที่มักได้ยินคือ “ฟรอนต์เอนด์คอยไล่ตามของใหม่แวววาวเสมอ และ React ก็เป็นหนึ่งในนั้น” แต่ React มีมาตั้งแต่ปี 2013 และราวปี 2015 ก็ถือว่าค่อนข้างเป็นกระแสหลักแล้ว
      อีกอย่าง มักบอกว่าเฟรมเวิร์กและไลบรารีเพิ่ม ความซับซ้อน แต่พอถามว่าซับซ้อนตรงไหนอย่างเป็นรูปธรรม แทบไม่ค่อยได้คำตอบเลย ถ้าสร้างแอปที่มีความหมายโดยไม่ใช้เฟรมเวิร์ก สุดท้ายก็มักจะลงเอยด้วยการประดิษฐ์เฟรมเวิร์กของตัวเองที่ขาดทั้งการดูแล การทดสอบ และเอกสารประกอบ
      ขั้นตอน compile และ bundling ก็ถูกบ่นบ่อย แต่ตอนนี้มีเฟรมเวิร์กที่พิสูจน์ตัวเองแล้วอย่าง Expo, Next.js, Meteor จึงแทบไม่มีเหตุผลให้ต้องตั้งค่า webpack หรือเขียน build pipeline เอง
    • เว็บไซต์ส่วนใหญ่ตั้งแต่แรกไม่จำเป็นต้องเป็น แอป เลย บางส่วนจำเป็น แต่กรณีแบบนั้นก็มักต้องทำแบบเฉพาะทาง
      กระแสที่ยัดเว็บเฟรมเวิร์กเข้าไปทุกที่ในช่วง 10 ปีที่ผ่านมา ผลิตไซต์ที่ช้าและพังง่ายออกมามากมาย และหลายครั้งแม้ออกแบบเกินจำเป็น แต่ประสบการณ์ผู้ใช้ก็ไม่ได้ดีขึ้นจากปี 2008 มากนัก
      สำหรับนักพัฒนาฟรอนต์เอนด์บางคน ไม่ว่าคำถามคืออะไร คำตอบคือชุดผสมของ React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit ฯลฯ และถ้าเป็นไปได้ต้องรันอยู่บน Docker swarm หลายสิบชุดที่ถูก Kubernetes ครอบงำ ประมาณว่า “อยากเอาเรซูเม่ขึ้นออนไลน์เหรอ? งั้นอีก 3 สัปดาห์ข้างหน้ามาวาดแผนภาพการไหลของ state ของแอปกัน”
      เหตุที่ React โดนด่าหนักเป็นพิเศษ น่าจะเพราะคนที่ไล่ตามกระแสเฟรมเวิร์กย้ายไปหาของแวววาวชิ้นถัดไปแล้ว ส่วนคนที่เดิมทีเกลียดเฟรมเวิร์กแบบนี้ก็ยังเกลียดอยู่ ทำให้ตอนนี้ไม่เหลือใครมาปกป้องความวุ่นวายนี้แล้ว เฟรมเวิร์กที่เหลือก็น่าจะเจอชะตากรรมเดียวกันเมื่อเวลาผ่านไป
    • ผมมองว่า React ยุคคลาสเป็น UI framework ที่โอเค ธรรมดา น่าเบื่อ แต่มีประโยชน์ ในทางกลับกัน hooks ใช้งานยากมาก
      การทำงานจริงถูกซ่อนไว้เยอะ ไม่เป็นธรรมชาติ ทำพลาดง่าย และเขียน UI ที่ประสิทธิภาพต่ำได้ง่าย
      ต้องคอยคิดตลอดว่าอะไรถูกเรียกกี่ครั้ง ต้องใส่อะไรใน dependency array และต้องใส่อะไรใน useCallback กับ useEffect ทำให้ภาระทางความคิดสูง
      คนบางส่วนในชุมชนยังแนะนำ dependency ของ React ที่โปรเจกต์ไม่จำเป็นต้องใช้ ทำให้มีแต่ overhead และความซับซ้อนเพิ่มขึ้น
      นอกจากนี้ business logic กับ UI logic ก็ปะปนกันได้ง่าย
    • jQuery พังหนักมากเมื่อเริ่มใช้สร้างแอปขนาดใหญ่และซับซ้อน คนที่ผ่านยุคนั้นมาจริง ๆ คงไม่น่าจะคิดถึงช่วงเวลานั้น
      ช่วงหนึ่ง SPA มีข้อเสียเมื่อเทียบกับ MPA แต่ด้วยมาตรฐานเว็บสมัยใหม่และการนำ server-side rendering มาใช้ใน SPA framework ปัญหาเหล่านั้นตอนนี้แทบได้รับการแก้ไขแล้ว
    • ไม่ใช่ว่า “ตอน NoSQL DB ออกมา ไม่มีใครบ่น” พวกเราหลายคนบ่นกันค่อนข้างดังว่า MongoDB แย่แค่ไหน
      https://www.youtube.com/watch?v=b2F-DItXtZs

  • เป็นรีลีสที่ยอดเยี่ยม แต่ก็อดคิดไม่ได้ว่าคนที่เพิ่งเริ่มเข้าสู่ การพัฒนาฟรอนต์เอนด์ ตอนนี้คงน่าสงสารอยู่บ้าง
    คำอธิบายอย่าง “เป็น hook ใหม่ที่จัดเรียง Action ภายใน Transition และเข้าถึงสถานะ action กับสถานะ pending ได้ โดยรับ reducer ที่เรียก Action ได้และสถานะเริ่มต้นที่ใช้ในการเรนเดอร์ครั้งแรก อีกทั้งยังรับสตริงแบบเลือกได้เพื่อรองรับ progressive enhancement ของฟอร์มเมื่อส่งให้กับ prop form action” แม้ฟีเจอร์จะดูดี แต่ก็ยืดยาวเกินไปมาก
    ถ้าเริ่มพัฒนาเว็บไซต์วันนี้ คงรู้สึกมืดแปดด้านว่าเริ่มจากตรงไหนดี
    ถึงอย่างนั้น React ก็ยังเป็นเฟรมเวิร์กที่ยอดเยี่ยม และรีลีสนี้ก็เป็นการปรับปรุงอยู่ดี คำวิจารณ์นี้ไม่ได้เจาะจง React อย่างเดียว แต่ใกล้เคียงกับภาพรวมของการพัฒนาฟรอนต์เอนด์ทั้งหมดมากกว่า

    • ถ้าจะให้คำแนะนำ ผมคงเริ่มจากการเลี่ยง React ไปเลยถ้าทำได้
      ใช้ server-side rendering แบบเก่าร่วมกับอะไรอย่าง HTMX จะดีกว่ามาก
      ผมหาเงินจากการพัฒนาฟรอนต์เอนด์ด้วย React มา 4 ปี และสร้างเว็บไซต์แรกในปี 2005 ตอนนี้กำลังย้ายโปรเจกต์ลูกค้ารายหนึ่งจาก React ไป HTMX และรู้สึกว่าดีกว่ามาก
      บั๊กก็น้อยกว่า กับดักจากการใช้ hook ผิดก็น้อยกว่า
      ถ้าจำเป็นต้องใช้ client-side rendering ผมคงใช้ Solid หรือ Vue แต่จะเลี่ยง React ถ้าไม่มีทางเลือกก็ขอให้โชคดี
    • ผมมองว่า React เป็นแนวทางที่น่าสนใจ แต่มี สัญญาณเตือน ที่ถูกมองข้ามมาตั้งแต่แรก
      สมมติฐานพื้นฐานอย่าง one-way binding, virtual DOM, การ re-render และการคำนวณ diff นั้นผมไม่เคยเห็นด้วยในระดับรากฐานเลย เท่ากับใช้หน่วยความจำเบราว์เซอร์เป็นสองเท่า และทำการ re-render ทั้งหมดกับคำนวณ diff ทุกครั้งที่มีปฏิสัมพันธ์
      ตอนนั้นคำตอบคือ “ทำให้เสถียรก่อน แล้วค่อยทำให้เร็ว” แต่ตอนนี้เต็มไปด้วยโครงสร้างแบบแฮ็กเพื่อทำให้เร็ว และก็ไม่ได้ทั้งเร็วหรือเสถียร
      เฟรมเวิร์กแบบ two-way binding ที่ตรงไปตรงมา อย่างน้อยก็รับประกันเรื่องความเร็วได้ ส่วนความเสถียรมาจากประสบการณ์ React นั้นแค่ชวนสับสน ผมรู้สึกเสียดายวิศวกรที่เริ่มฟรอนต์เอนด์ครั้งแรกด้วย React เพราะการลบสิ่งที่เรียนมาแล้วเรียนใหม่คงยากกว่าการเรียนตั้งแต่แรกมาก
      จากมุมมองของคนที่ผ่าน VBScript, JS, jQuery, Mootools, Applets, ActionScript, YUI/Ext/Sencha, Backbone, Knockout, Angular 1, Angular 2, React, Vue 1 มาแล้ว ผมอยากบอกให้ลอง Flutter ดู มันสดใหม่จริง ๆ
      แต่ปัญหาคือ Dart ถ้า Flutter เป็น TypeScript ก็คงใกล้อุดมคติมากขึ้นอีกหน่อย แต่ Dart ยังทำให้จิตวิญญาณ churn ไม่รู้จบของฟรอนต์เอนด์ยังคงมีชีวิตต่อไป
    • ผมกลับรู้สึกตรงกันข้าม ตอนที่ผมเริ่มใช้ React มันเปลี่ยนทุกไม่กี่สัปดาห์ แต่ตอนนี้เอกสารกับ API เสถียรและสอดคล้องกันมากขึ้นมาก
      มาตรฐานเว็บโดยรวมก็เสถียรกว่าที่เคยเป็นมา นักพัฒนารุ่นใหม่ไม่จำเป็นต้องเรียนรู้ทริกเลย์เอาต์เป็นร้อย ๆ แบบเพื่อให้หน้าเว็บแสดงผลถูกต้องในหลายเบราว์เซอร์ และบางครั้งก็ไม่ต้องใช้แฮ็กเพื่อรองรับแค่เบราว์เซอร์เดียวมากเท่าเดิม
      ผมเข้าใจความเหนื่อยล้าจาก JavaScript แต่ผมมองว่าตอนนี้เป็นหนึ่งในช่วงเวลาที่ดีที่สุดสำหรับการเรียนรู้
    • ผมทำโค้ดระดับต่ำเป็นหลัก และโดยมากไม่ชอบจุดที่ต้องเกี่ยวข้องกับเว็บฟรอนต์เอนด์ แต่เมื่อหลายปีก่อนลองจับ React ในโปรเจกต์ส่วนตัวแล้วประหลาดใจมาก
      ทุกอย่างให้ความรู้สึกเหมือนเป็น การพัฒนาที่ถูกต้องจริง ๆ และเมื่อเทียบกับสถานการณ์ก่อนหน้า มันเหมือนสูดอากาศบริสุทธิ์
    • ผมมองว่าเริ่มต้นง่ายนะ แค่ไม่ใช้ฟีเจอร์ทางเลือกนั้นก็พอ
      ถ้าเป็นนักพัฒนา 99% ก็คงไม่ต้องใช้ฟีเจอร์แบบนั้นจนกว่าแอปจะโตถึงระดับหนึ่ง และอาจไม่ต้องใช้เลยจนจบก็ได้ React ก็ไม่ได้บังคับ

  • ครั้งหนึ่งผมเคยชอบเฟรมเวิร์กฝั่งไคลเอนต์อย่าง React แต่สุดท้ายก็รู้ว่ามันเพิ่ม ความซับซ้อน ให้ทุกที่ที่เป็นไปได้
    ทั้งแบ็กเอนด์ ฟรอนต์เอนด์ และสแต็ก DevOps ล้วนมีความซับซ้อนแทรกเข้าไป และเพื่อซิงก์ความซับซ้อนที่กระจายตัวเหล่านั้น ก็จะมีเลเยอร์เพิ่มเข้ามาเรื่อย ๆ

    • เมื่อเกินกว่าแอปพลิเคชันขนาดเล็ก เฟรมเวิร์กฟรอนต์เอนด์ทำให้สิ่งต่าง ๆ เรียบง่ายขึ้นจริง
      การที่ UI re-render อัตโนมัติเมื่อข้อมูลหรือโมเดลเปลี่ยน เป็นทิศทางที่ถูกต้อง
      รายละเอียดวิธีทำอาจถกเถียงกันได้ แต่การต้องแก้ UI เองแบบ imperative ทุกครั้งที่ข้อมูลเปลี่ยน เป็นแนวทางที่อยู่ได้นานยากทั้งในแง่ codebase และขนาดทีม
    • React คือเหตุผลที่ทำให้ผมถอยห่างจากเว็บฟรอนต์เอนด์
      มันโปะความซับซ้อนมหาศาลเพื่อทำให้เว็บเบราว์เซอร์เรนเดอร์กล่องในแบบที่เดิมทีไม่ได้ตั้งใจไว้ และยังสูญเสียผลิตภาพกับระบบเครื่องมือไปมากภายใต้ข้ออ้างว่าจะเปลี่ยนพาราไดม์การเขียนโค้ด
      มีไอเดียและการนำไปใช้งานที่เจ๋งอยู่ แต่ไม่แน่ใจว่าคุ้มค่าขนาดนั้นไหม บางทีก็รู้สึกเหมือนเป็นกลไกรักษาความมั่นคงในอาชีพ
      ไม่ใช่ปัญหาของ ReactJS อย่างเดียว ระบบนิเวศ JavaScript ทั้งหมดก็คลั่งไคล้ไลบรารีและเครื่องมืออยู่แล้ว แต่ React นั้นเริ่มต้นใช้งานน่ารำคาญเป็นพิเศษ จนสุดท้ายต้องมี create react app ออกมาเพื่อให้สร้างแอป hello world ได้ภายในเวลาที่สมเหตุสมผล
    • ผมคิดว่าเป็นเพราะการพัฒนาซอฟต์แวร์ที่ได้เงินลงทุนจาก VC เป็นโครงการสวัสดิการสำหรับคนฉลาดที่ต้องการความสนุกด้วย ก็โอเคนะ
    • ผมชอบ React แต่หลังจาก v16.8 ที่มี hooks การเปลี่ยนแปลงของ React ให้ความรู้สึกเหมือนอวดเทคนิค
      ผมเลิกคาดหวังว่าจะเข้าใจเหตุผลที่เปลี่ยน API ของ class component ไปเป็น hook แล้ว
    • ควรย้อนดูด้วยว่าเราเป็นคนเพิ่มความซับซ้อนเองหรือเปล่า
      อาจเลือกเฟรมเวิร์กที่เรียบง่ายกว่านี้ได้ หรืออาจเลี่ยง server orchestration ได้
      ถ้าไม่มีทางเลือก ก็อาจเริ่มโปรเจกต์เองที่เชื่อว่าสแต็กที่เรียบง่ายจะให้ความได้เปรียบด้านประสิทธิภาพ

  • หนึ่งในส่วนที่ดีที่สุดของรีลีสนี้คือ สามารถใช้ ref เป็น prop ได้แล้ว ตอนนี้จึงไม่จำเป็นต้องใช้ forwardRef อีกต่อไป

  • บทความบล็อกอ่านง่ายกว่า: https://react.dev/blog/2024/12/05/react-19

    • ตรง const error = await updateName(newName); ผมไม่เข้าใจว่าทำไม updateName ถึงคืน error
      ตามสไตล์ JS/TS แล้ว แค่โยน Error ไม่ได้หรือ?

  • ถ้าจากคอมเมนต์ 45 รายการจนถึงตอนนี้มีการพูดถึง “redux” 7 ครั้ง ที่นี่ผมอยากพูดถึง Jotai ในฐานะตัวแทนสาย Recoil ดูบ้าง เป็นไปได้สูงว่ามันน่าจะทำงานบน React 19 ได้อยู่แล้วโดยไม่ต้องเปลี่ยนอะไรเป็นพิเศษ
    เมื่อความซับซ้อนของฟรอนต์เอนด์ใหญ่พอ เครื่องมือจัดการ state อื่น ๆ ก็มักจะกลายเป็นตัวขัดขวางเกินจำเป็น
    ถ้าคุณเริ่มไม่ชอบ React แต่จริง ๆ แล้วเป็นเพราะเหนื่อยกับกำแพง action constants ที่ไม่มีที่สิ้นสุด, การเดินสาย prop, การต่อสู้กับ provider/context ที่ซ้อนกัน และการหนีไปพึ่ง pub-sub ก็น่าลองใช้อะไรอย่าง Jotai ดู

    • ทีมที่สร้าง Jotai ยังเป็นผู้สร้าง Zustand และ Valtio ด้วย
      https://github.com/pmndrs/zustand
      https://github.com/pmndrs/valtio
      Jotai ให้ความรู้สึกว่ามี boilerplate แบบลงมือเองมากเกินไป ส่วน Valtio ก็มี “เวทมนตร์” จาก proxy เยอะ แม้โดยส่วนตัวจะชอบ แต่ก็ไม่แน่ใจว่าเป็นตัวเลือกที่ดีสำหรับทีมหรือไม่
      Zustand อยู่กึ่งกลางระหว่าง boilerplate กับเวทมนตร์ เลยเลือกใช้กับโปรเจกต์ใหญ่ที่กำลังทำอยู่ตอนนี้
    • ไม่เข้าใจว่าทำไมการจัดการ state ถึงมีศัพท์แปลก ๆ เยอะขนาดนั้น
      เมื่อไม่กี่ปีก่อน ตอนเริ่มทำแอป React แพ็กเกจจัดการ state ทุกตัวที่เห็นก็เต็มไปด้วยศัพท์พวกนั้น และตอนนี้ก็ยังเหมือนเดิม
      สุดท้ายเลยสร้างโซลูชันเองเพื่อหนีจากสิ่งเหล่านั้นและโฟกัสกับงาน [1] ซึ่งทำงานได้ดีใน production น่าเสียดายที่ไม่มีตัวเลือกยอดนิยมที่ทำงานคล้ายกัน
      [1] https://github.com/facepunch/react-class-model
    • แม้จะดูหน้าเอกสาร npm ของ Jotai (https://www.npmjs.com/package/jotai) ก็ยังไม่ค่อยเห็นภาพว่ามันช่วยให้หลุดจากการใช้ context provider หลายตัวหรือ Redux ได้อย่างไร
      ข้อดีของ context hook คือมันประกอบเข้าด้วยกันได้ และเมื่อจับคู่กับ cached query ก็สร้างแพตเทิร์นที่ดูแลรักษาได้พอสมควร
      อยากรู้ว่า Jotai ให้ การปรับปรุงที่เป็นรูปธรรม อะไรตรงนี้
    • เคยใช้ Jotai ในโปรเจกต์ที่ค่อนข้างใหญ่ และค่อนข้างชอบ
      หวังจริง ๆ ว่าจะไม่ต้องยุ่งกับ redux หรือ sagas อีก
    • อยากให้ทุกคนลอง https://starfx.bower.sh เป็นแนวทางใหม่สำหรับการจัดการ state และที่สำคัญกว่านั้นคือ การจัดการ side effects

  • ฟีเจอร์ใหม่ส่วนใหญ่ไม่ค่อยถูกใจ
    Actions กับ hook useActionState / useOptimistic ดูเหมือนเป็น กับดักความซับซ้อน ขนาดใหญ่ hook use ก็เป็นชื่อที่ไม่สื่อข้อมูลมากเกินไป และไม่จัดการ promise ที่สร้างขึ้นภายในคอมโพเนนต์
    แน่นอนว่าคงมีเหตุผลที่ดี แต่แนวทางส่ง promise ผ่าน prop แล้วจัดการด้วย hook use น่าจะสร้างความซับซ้อนมากกว่าวิธีเลี่ยงที่ใช้อยู่ตอนนี้
    Server Components ก็ดูค่อนข้างซับซ้อน และดีแล้วที่ยังไม่มีงานที่ต้องไปยุ่งกับมัน
    การปรับปรุงข้อความ error ของ hydration เป็นเรื่องน่ายินดี และการเปลี่ยนให้ใช้เป็น provider กับการเปลี่ยนให้ใช้ ref เป็น prop ก็เป็นการปรับปรุงคุณภาพที่ดี
    โดยรวมแล้วสำหรับการสร้าง SPA ผมชอบ React/Preact ถ้าใช้ร่วมกับไลบรารีคอมโพเนนต์ที่ฟีเจอร์ครบอย่าง MUI และโซลูชันจัดการ state แบบเรียบง่ายอย่าง Preact Signals การทำ SPA ก็ค่อนข้างตรงไปตรงมา
    แต่กังวลว่าความซับซ้อนกำลังค่อย ๆ แทรกเข้ามา แค่อ่านคำอธิบาย hook ใหม่ใน release notes ก็รู้สึกว่าภาระทางความคิดสูงมากแล้ว
    ในทางกลับกัน React Compiler เป็นเครื่องมือที่จำเป็นจริง ๆ เพราะโปรแกรมเมอร์จะไม่ต้องเขียน optimization แบบทั่วไปไว้ในคอมโพเนนต์เอง ทำให้คอมโพเนนต์ซับซ้อนน้อยลง
    ตั้งตารอ release และการ integrate กับ Vite เป็นต้น และเท่าที่ได้ยินมา Preact ก็จะรองรับด้วย

  • อยากให้เปลี่ยนชื่อ API use เป็นชื่ออื่นที่ต่างจาก prefix ร่วมของ hook
    คนที่เพิ่งเริ่มใช้ React hooks อาจสับสนเมื่อเห็นว่า use เรียกแบบมีเงื่อนไขได้ แต่ hooks ทั่วไปทำไม่ได้

  • ดีใจจริง ๆ ที่เลื่อน release เพื่อแก้ปัญหา Suspense แบบขนาน
    ยังไม่ได้ลองใช้ แต่คาดหวังไว้มาก และโดยรวมเป็น release ที่ยอดเยี่ยม

  • ข่าวด่วน: รองรับ custom elements อย่างเต็มรูปแบบ นั่นก็คือ Web Components