เนื่องจากเนื้อหาของงาน 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 ต่าง ๆ เกิดขึ้นมามากมายเช่น

เรื่องที่สาม ว่าด้วยเรื่องของ 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 ในครั้งต่อไป