สรุปเนื้อหาในช่วงบ่ายของงาน React Bangkok 3.0.0

เนื่องจากเนื้อหาของงาน React Bangkok 3.0.0 นั้นเยอะและแน่นมาก จึงทำการแยกเนื้อหาในช่วงบ่ายออกมาเป็น blog ที่สอง ดูรายละเอียดของ session ช่วงเช้าได้ ซึ่งประกอบไปด้วยหัวข้อดังนี้

• การจัดการ State ด้วย MobX
• Animating in React (ภาษาอังกฤษ)
• ว่าด้วยเรื่อง React Design Pattern
• ประสบการณ์ในการใช้งาน Expo และ GraphQL
• ประสบการณ์การพัฒนาระบบงานด้วย React ของ Telenor
• การ Tuning performance ของ React app
• การทดสอบสำหรับ React app
• ว่าด้วยเรื่องการจัดการ State ของ React app ประเด็นคือเลือกใช้แต่ละอย่างด้วยเหตุผลอะไร

ทำการสรุปแบบสั้น ๆ ไว้นิดหน่อย มาดูกันเลย

เรื่องแรก การจัดการ State ของ React App

เนื่องจากในช่วงบ่ายนั้นมี session ที่พูดถึง การจัดการ State ใน React app เยอะมาก เนื่องจากมีวิธีการและ library เพียบ ยกตัวอย่างเช่น

• ​React เพียว ๆ นั่นคือใช้ props นั่นเอง
• Redux และผองเพื่อน
• MobX

ประเด็นสำคัญคือ เราทำการเลือกใช้งานสิ่งต่าง ๆ เหล่านี้ด้วยเหตุผลอะไร ? ความชอบ ? อยากใช้ ? ตามคนอื่น ? ตามความนิยม ? รู้แค่ตัวเดียว ? สิ่งที่น่าสนใจจาก session สุดท้ายคือ พยายามอธิบายว่า ก่อนที่เราจะเลือกใช้อะไรนั้น ควรต้องเข้าใจเป้าหมายทาง business ของระบบ จากนั้นต้องรู้ว่า ระบบเรานั้นมี data-flow ที่ใช้งานนั้นเป็นอย่างไร ? ยกตัวอย่างเช่น ถ้าระบบงานมีข้อมูลที่ใช้งานแยกกันหรือแบ่งตามหน้าจอแล้ว การใช้งานเพียง React เพียว ๆ หรือใช้งาน MobX ก็เพียงพอ แต่ถ้าข้อมูลในหนึ่งหน้ามีการใช้ข้อมูลจำนวนมาก ๆ แล้ว และมีการ share ข้อมูลระหว่างหน้าเยอะมาก ๆ ดังนั้นการนำ Redux มาใช้น่าจะเหมาะสมกว่า ดังนั้นคำถามแรกคือ คุณรู้และเข้าใจข้อมูลที่ระบบต้องการหรือไม่ ?

สรุปคือ รู้ตัวเอง รู้ความต้องการ จากนั้นจึงเลือก

เรื่องที่สอง Animating in React

เป็น session ที่น่าสนใจมาก ๆ และ unique มาก ๆ เพราะว่า ไม่มีงานไหนพูดเรื่องของการจัดการ animation เลย เนื้อหาหลัก ๆ ประกอบไปด้วย

1. ​ต้องรู้ปัญหาของการทำ animation
2. การสื่อสารเรื่องของ animation ออกไป แยกออกเป็น trigger -> action -> quality
3. การพัฒนา ซึ่งมี library เยอะมาก ๆ ทั้งแบบ native และ 3-party library

มาดูรายละเอียดกัน สิ่งที่สำคัญมาก ๆ คือ ปัญหาที่เกิดจากการทำ Animation ซึ่งเราต้องรู้และจัดการให้ได้ทั้ง

• เมื่อใดที่ animation จะทำงานเสร็จ (Done)
• เมื่อใดที่ animation กำลังทำงานอยู่ (In progress)
• Animation ทำงานงานเท่าไร (How long ?)
• ผู้ใช้งานไม่ต้องการรอ จัดการอย่างไร
• ต้องแสดงสิ่งที่ผู้ใช้งานต้องการจะเห็นก่อนเสมอ
• Animation ที่ดีต้องมีความเป็นธรรมชาติ
• Animation ต้องไม่น่าเบื่อ !!

เรื่องที่สองคือ เราจะสื่อสารเรื่องของ animation ออกไปอย่างไร ซึ่งใน session แบ่งออกเป็น 3 ส่วนคือ ส่วนที่ 1 คือ Trigger นั่นคือจะเกิดเหตุการณ์ต่าง ๆ อย่างไร เช่นเมื่อ page loaded เสร็จแล้ว และการกดปุ่มเป็นต้น ส่วนที่ 2 คือ Action สิ่งที่จะต้องทำหลังจากที่เกิดเหตุการณ์ต่าง ๆ ขึ้นมา ตรงนี้นั่นเองที่เราต้องพัฒนาขึ้นมา ส่วนที่ 3 คือ Quality ว่าด้วยเรื่องของคุณภาพของ animation ที่สร้างขึ้นมา ทั้งใช้เวลาการทำงานเท่าไร ทั้งการทำงานของ animation เป็นธรรมชาติหรือไม่ ทั้งการใช้งานง่ายหรือไม่ ทั้งประสิทธิภาพของการทำงานเป็นอย่างไร ซึ่งจะสอดคล้องกับ property ที่เลือกใช้งาน เช่น สี ขนาด และ ตำแหน่งเป็นต้น เรื่องที่สามคือ การพัฒนา โดยสามารถพัฒนาด้วย native library ได้ เช่น CSS, Canvas และ webGL เป็นต้น แต่การพัฒนาและจัดการไม่ง่ายเลย ดังนั้นจึงมี library ต่าง ๆ เกิดขึ้นมามากมายเช่น

• ​GreenSock (GSAP)
• Velocity React
• React Motion
• React Move

เรื่องที่สาม ว่าด้วยเรื่องของ React Design Pattern

ปัญหาของการพัฒนาระบบส่สวนใหญ่คือ เมื่อระบบใหญ่ขึ้น จำนวน feature มากขึ้นแล้ว จำนวน code ก็เยอะขึ้น ถ้าจัดการและออกแบบ code ไม่ดีแล้ว อาจจะทำให้เกิดปัญหาในการดูแลรักษาก็เป็นได้ หรือเราอาจจะเรียก code ที่มีปัญหาว่า Legacy code หรือ Spaghetti code

ใน session ได้อธิบายวิวัฒนาการของ design pattern ที่ใช้งาน พร้อมอธิบายข้อดีข้อเสีย รวมทั้งแนวทางการแก้ไข มาดูกันว่ามีอะไรบ้าง

เริ่มต้นเราก็จะใช้งานตาม React standard ปกติ แต่เมื่อ code เยอะขึ้น จำนวน component เยอะขึ้น สิ่งที่เกิดขึ้นคือ ความซ้ำซ้อน เช่น เรามักจะมี Dumb component จำนวนมาก ในแต่ละ component อาจจะใช้ data ชุดเดียวกัน ในแต่ละ component อาจจะมี function การทำงานหรือพฤติกรรมการทำงานเหมือนกัน คำถามคือ เราจะลดความซ้ำซ้อนนี้ลงไปอย่างไร ? เพราะว่า มันเป็นปัญหาที่การพัฒนาระบบงานต้องพึงระวัง หนึ่งในวิธีการแก้ไขจาก session คือ HOC (Higher-Order Component) เป็นรูปแบบของ function ที่รับ component เข้าไป แล้วได้ component ใหม่ออกมาพร้อมกับข้อมูลที่จำเป็นต่อการใช้งาน แต่ก็ยังมีข้อเสีย เมื่อ component มีความซับซ้อน เช่น A -> B -> C-> D โดยที่ A ต้องส่งข้อมูลบางอย่างไปให้ D แต่ B กับ C ไม่ใช้งาน ทำให้เกิดงานที่ไม่จำเป็นจำนวนมาก การตั้งชื่อก็สำคัญมาก ๆ สำหรับ HOC ถ้าตั้งชื่อแย่แล้ว ของที่ดี ๆ จะเสียหมดเลย รวมไปถึงชื่อ props ต้องต่างกันด้วยนะ ไม่งั้นเกิดปัญหาแน่ ๆ (Props collision) ยังไม่พอนะ ถ้าใช้งานผิดทาง ซึ่งเกิดได้ง่ายมาก จะทำให้มีแต่ปัญหามากกว่าประโยชน์ ดังนั้นต้องใช้งานอย่างระมัดระวัง อย่างเข้าใจ ใน session จึงขอแนะนำวิธีการใหม่ ๆ คือ Function as Children หรือ Render Props วิธีการนี้ใช้ความสามารถของ props ซึ่งสามารถส่งข้อมูลชนิดอะไรไปก็ได้ วิธีการนี้จึงทำการส่ง function ผ่าน props เข้าไปยัง Child component นั่นเอง ดังนั้นในการออกแบบ React component จะแบ่งเป็นดังนี้

• ​Parent component จะมี function การทำงาน เช่นการดึงข้อมูล เป็นต้น
• Child component หรือ Dumb component ทำการรับ function ผ่าน props จาก Parent component

ใน session ยังได้บอกอีกว่า จะใช้วิธีการใดก็ตาม แนะนำให้เข้าใจมันจริง ๆ รวมทั้งทีมต้องเข้าใจด้วย ถ้าทำงานเป็นทีม ปิดด้วยให้สร้าง Dumb component (Stateless component) ให้เยอะที่สุด

แต่ทั้งหมดทั้งมวลใช้ React Context ก็ได้นะ ซึ่งมันเป็น Render props นี่แหละ ลองใช้งานกันดูได้

เรื่องที่สี่ การ Tuning performance ของ React app

เป็นการแบ่งปันประสบการณ์ของการปรับปรุงประสิทธิภาพการทำงานของ React app ซึ่งเป็นระบบที่พัฒนาด้วย Apache Cordova นั่นคือ Hybrid app นั่นเอง (iOS และ Android) โดยเลือกใช้ React ในการเขียน เมื่อเริ่มต้นพัฒนานั้น ทุกสิ่งอย่างดูสวยงาม น่าพัฒนาอย่างมาก ทำงานเร็วมาก แต่เมื่อเวลาผ่านไประบบทำงานช้าลงมาก code แก้ไขยากมาก ระบบงานแย่ลงอย่างต่อเนื่อง ดังนั้นจึงเข้าสู่จุดเริ่มต้นของการปรับปรุง code กันแล้ว เริ่มจากต้องทำความรู้และเข้าใจการทำงานของระบบกันก่อน ด้วย Google Chrome Dev Tools และ React Perf Dev Tools จากนั้นจึงลงมือแก้ไขปัญหากัน ใน session สรุปปัญหาที่แก้ไขมาให้ดูดังนี้

• ทำการ render ใหม่ทั้งหมดเมื่อข้อมูลตัวใดตัวหนึ่งเปลี่ยนแปลง ด้วยการใส่ key label และ shouldComponentUpdate และทำการ caching ข้อมูลพวก state และ props ด้วย React Memoize
• ทำการ mount ข้อมูลที่จะถูกแสดงผลในหน้าจอเท่านั้น ด้วยการใช้งาน React Virtualized

เรื่องที่ห้า การทดสอบ React App

เป็นอีกเรื่องที่พูดถึงกันน้อยมาก แต่ทุกครั้งในงาน React Bangkok จะมีเรื่องนี้เสมอ โดยในครั้งนี้ session ประกอบไปด้วยหัวข้อต่าง ๆ ดังนี้ ทำไมถึงต้องทดสอบ ? เพื่อช่วยให้การแก้ไขระบบเร็วขึ้น ถ้าชุดการทดสอบดีนะ เพื่อช่วยอธิบายการทำงานของ code ในส่วนต่าง ๆ สุดท้ายที่สำคัญมาก ๆ คือ เพิ่มความมั่นใจต่อระบบนั่นเอง (Confidence) โดยใน session นี้จะเน้นในเรื่องของ confidence เป็นพิเศษ ทำการอ้างอิงไปยัง Test Pyramid ประกอบไปด้วย Unit, Integration และ UI test คำถามที่ตามมาคือ ทำไมไม่ทดสอบแต่ Unit test ไปเลย ? เพราะว่า ทำงานก็เร็ว ค่าใช้จ่ายก็ถูกกว่า คำตอบคือ เรื่องของความเชื่อมั่นล้วน ๆ ไงละ ยิ่งทดสอบในระดับที่สูงขึ้น ทั้ง Integration และ UI test ยิ่งเพิ่มความเชื่อมั่นให้สูงขึ้น โดยใน session แนะนำให้ทดสอบในระดับ integration ขึ้นมา และอย่าลงไปทดสอบในระดับ detail of implementation มากไป เพราะว่า ถ้าเปลี่ยนนิดหน่อย ก็จะทำให้ชุดการทดสอบพังเยอะมาก ๆ ดังนั้นให้ทดสอบผ่าน API/Interface แทนจะดีกว่า รวมทั้งเน้นว่า ให้ทดสอบจากมุมมองของผู้ใช้งานเป็นหลัก เครื่องมือและ library ที่ใช้ประกอบไปด้วย ​Enzyme และ React DOM โดยตามจริงใช้เพียง React DOM ก็ได้ และใช้งานร่วมกับ react-testing-library ช่วยทำให้เข้าถึง element ต่าง ๆ ได้ง่ายและสะดวกมากยิ่งขึ้น

ปิดท้ายด้วยเครื่องมือสุดแจ่มคือ Cypress  คือ End-to-End test framework สำหรับ JavaScript ซึ่งประกอบไปด้วย library ที่จำเป็นต่อการทดสอบมาให้ครบ เช่น Mocha, Chai และ Sinon เป็นต้น รวมทั้งมีความสามารถที่จำเป็นเช่น Screenshot และ VDO record การทดสอบ

ปิดด้วยการประกาศจากผู้จัดงานว่า

ไม่มีอีกแล้วสำหรับงาน React Bangkok เจอกันกับ JavaScript Bangkok ในครั้งต่อไป