ที่Storylyเรามีโปรเจ็กต์ React สองโปรเจ็กต์ที่แตกต่างกันมาก อันหนึ่งคือ "แดชบอร์ด" และอีกอันคือ "สตูดิโอ"

โครงการทั้งสองนี้แตกต่างกันในวัตถุประสงค์เช่นเดียวกับความท้าทายทางเทคนิค แดชบอร์ดคือโครงการ CMS ที่ผู้ใช้ของเราจัดการแอป อินสแตนซ์ กลุ่มเรื่องราว การตั้งค่า และการผสานรวม และดูการวิเคราะห์ของพวกเขา ในทางกลับกัน โครงการ Studio เป็นเครื่องมือในการออกแบบ ช่วยให้ผู้ใช้ของเราออกแบบเรื่องราวของพวกเขาบนผืนผ้าใบที่ว่างเปล่าโดยใช้องค์ประกอบที่กำหนดไว้ล่วงหน้าของเรา

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

เราในฐานะนักพัฒนาส่วนหน้าไม่ควรทำการตัดสินใจทางเทคนิคเฉพาะในด้านเทคนิคเท่านั้น มีแง่มุมอื่นๆ อีกมากมายที่ต้องพิจารณา รวมถึงทีม ผู้ใช้ปัจจุบันและที่เป็นไปได้ อนาคตที่ตั้งใจไว้ของโครงการ และวัฒนธรรมของบริษัท ทั้งหมดนี้จะมีผลกระทบต่อโซลูชันทางเทคนิคของคุณโดยพื้นฐานในระหว่างกระบวนการตัดสินใจ

สมมติว่างานของคุณคือเลือกโซลูชันการจัดการสถานะสำหรับโครงการของคุณ มีอยู่มากมายที่มีข้อเสียและข้อดีที่แตกต่างกัน พูดได้อย่างปลอดภัยว่าหัวข้อการจัดการสถานะในระบบนิเวศส่วนหน้ามาพร้อมกับโซลูชันจำนวนมากถัดจากหัวข้อ "เฟรมเวิร์ก"

หากคุณพิจารณาเฉพาะข้อดีและข้อเสียทางเทคนิค ตัวเลขประสิทธิภาพ โซลูชันที่ใช้งานง่าย และบางทีจำนวนคอมมิชชัน ดาว และปัญหาของโซลูชันจะเป็นสิ่งที่คุณกำลังตรวจสอบ และทั้งหมดนี้เป็นประเด็นที่ถูกต้องเมื่อเลือกห้องสมุด

เมื่อฉันดูโซลูชันการจัดการสถานะเพื่อใช้ในโค้ดเบสทั้งสองจากมุมมองทางเทคนิค ฉันมีแนวโน้มที่จะใช้ Zustand หรือ Jotai พวกมันได้รับการบำรุงรักษาอย่างดี ใช้งานง่ายอย่างไม่น่าเชื่อ และมีประสิทธิภาพ มันเป็นการตัดสินใจที่ง่ายใช่ไหม?

เรากำลังใช้ Redux ที่ยิ่งใหญ่ในโค้ดเบสทั้งสองของเราเพื่อจัดการสถานะของมัน และฉันจำเป็นต้องทำให้ส่วนนี้ของโปรเจ็กต์ง่ายขึ้นเพราะมันขยายขอบเขตมากขึ้นกว่าที่ควรจะเป็น มันเป็นแหล่งที่มาหลักของจุดบกพร่องจำนวนมากของเรา ฉันคิดทันทีว่า “โอ้ เยี่ยมมาก เราควรใช้ Zustand กับทั้งสองโปรเจกต์เพราะมันน่าทึ่งมาก!” แต่แล้วฉันก็ถอยออกมาหนึ่งก้าวและไตร่ตรองอีกเล็กน้อย

กระบวนการโยกย้าย

อย่างที่ฉันอธิบายไปในตอนต้น ฐานรหัสทั้งสองของเรานั้นแตกต่างกันมาก

แดชบอร์ดแสดงข้อมูลฝั่งเซิร์ฟเวอร์ให้ผู้ใช้ทราบโดยมีการเปลี่ยนแปลงเล็กน้อยและปรับปรุงข้อมูลฝั่งเซิร์ฟเวอร์ มีหน้าเว็บจำนวนมากที่มีข้อมูลการวิเคราะห์ รายการ และสถิติที่คำนวณไว้ อนาคตของโครงการนี้ก็จะคล้ายกันเช่นกัน แดชบอร์ดแบบ CMS ที่มีสถิติและรายการมากมาย ดังนั้นฉันจึงต้องพิจารณาการแคชข้อมูล การทำให้แคชใช้ไม่ได้ น้ำตกเครือข่าย การอัปเดตข้อมูลตามเวลาจริง การอัปเดตในแง่ดี ฯลฯ เมื่อคำนึงถึงหัวข้อเหล่านี้ ฉันตัดสินใจว่าเราไม่จำเป็นต้องเปลี่ยนโซลูชันการจัดการสถานะของเรา (Redux ); เราเพียงแค่ต้องลบออกจากแดชบอร์ดเพราะเราไม่ต้อง "จัดการ" สถานะใดๆ

จากนั้นฉันดูโซลูชันการดึงข้อมูล เช่นSWR , TanStack QueryและRTK Query

SWR ไม่มีโฟลว์การกลายพันธุ์ที่เสถียร และ RTK Query จับคู่กับ Redux Toolkit มากเกินไป ดังนั้นฉันจึงใช้ TanStack Query ไปก่อน

TanStack Query ลบค่าใช้จ่ายในการจัดการข้อมูลฝั่งเซิร์ฟเวอร์ด้วยโฟลว์การแคช การทำให้ไม่ถูกต้อง และการกลายพันธุ์ มีสถานะให้จัดการอยู่เสมอ แต่คุณไม่จำเป็นต้องจัดการด้วยตัวเองเสมอไป เราได้มอบภาระหนักนี้ให้กับ TanStack Query และไม่หันกลับมามอง เรากำลังใช้ Redux และ TanStack Query ในแบบคู่ขนานและย้ายสถานะ Redux ทีละชิ้นไปยังแบบสอบถาม TanStack จนกว่าจะไม่มีอะไรเหลืออยู่ในสถานะ Redux และเราสามารถทำได้อย่างyarn removeปลอดภัย

React Hooks ช่วยให้เราสามารถใช้พวกมันแบบขนานและย้ายตรรกะระหว่างพวกมันทีละน้อย:

อย่างไรก็ตาม ในสตูดิโอมีข้อมูลฝั่งไคลเอนต์จำนวนมากที่สร้างขึ้นเพื่อส่งไปยังเซิร์ฟเวอร์ คุณสามารถออกแบบเรื่องราวได้อย่างสมบูรณ์ด้วยองค์ประกอบที่กำหนดไว้ล่วงหน้า คุณสามารถย้ายไปมาในผืนผ้าใบ ปรับขนาด เปลี่ยนเนื้อหาตามความต้องการของคุณ เปลี่ยนภาพพื้นหลังของเรื่องราว หรือแม้กระทั่งใส่วิดีโอในพื้นหลัง และความเป็นไปได้ไม่มีที่สิ้นสุดก่อนที่คุณจะส่งข้อมูลสุดท้ายไปยังเซิร์ฟเวอร์เพื่อบันทึก คุณลักษณะทั้งหมดเหล่านี้เป็นข้อมูลฝั่งไคลเอ็นต์จนกว่าคุณจะบันทึก และหลังจากที่คุณบันทึกและกลับไปแก้ไข ข้อมูลเหล่านั้นจะเป็นข้อมูลฝั่งไคลเอ็นต์ที่ได้รับมาจากข้อมูลฝั่งเซิร์ฟเวอร์อีกครั้ง

เราต้องคิดถึงคุณสมบัติที่เป็นไปได้ด้วย — ความสามารถในการเลิกทำการเปลี่ยนแปลง สร้างภาพวาดด้วยมือเปล่า ออกแบบการเปลี่ยนระหว่างเรื่องราว… ความเป็นไปได้ไม่มีที่สิ้นสุด แต่คุณสมบัติที่เป็นไปได้ทั้งหมดคือข้อมูลจำนวนมากฝั่งไคลเอ็นต์ ดังนั้นเราต้อง "จัดการ" สถานะของเราที่นี่เพื่อความคล่องตัวสูงสุด

สำหรับสตูดิโอ เราใช้โซลูชันการจัดการสถานะ Redux อยู่แล้ว ผมจึงถามเพื่อนร่วมทีมว่า “เราควรใช้อะไรแก้ไขการจัดการสถานะของเรา”

หลังจากการ ตอบกลับทั้งหมด เส้นทางก็ชัดเจน: เราจะใช้Redux Toolkit

RTK (Redux Toolkit) เป็นชุดเครื่องมือจากทีม Redux เพื่อปรับปรุงคุณภาพชีวิตของนักพัฒนา ช่วยลดความยุ่งยากในการกำหนดค่าของร้านค้าและการจัดการร้านค้าหลายแห่งโดยใช้สไลซ์ ดังนั้นเราจึงย้ายสถานะ Redux เก่าของเราไปยังสถาปัตยกรรม RTK ใหม่ เรากำลังเรียกใช้สถาปัตยกรรมทั้งเก่าและใหม่เคียงข้างกัน และย้ายชิ้นส่วนของรัฐไปยังสถาปัตยกรรมใหม่ในขณะที่ปรับโครงสร้างใหม่ ทั้งหมดนี้ช่วยให้เราสามารถดำเนินการได้อย่างรวดเร็วและเพิ่มขึ้นในขณะที่ไม่ปิดกั้นเวิร์กโฟลว์ของผลิตภัณฑ์

เรากำลังเรียกใช้สถาปัตยกรรมทั้งเก่าและใหม่ควบคู่กันไปโดยส่งReact Context ที่กำหนดเองไปยังผู้ให้บริการ Redux :

โปรดทราบว่าเมื่อคุณส่งบริบทที่กำหนดเองไปยังผู้ให้บริการ Redux คุณต้องสร้าง Redux hooks ที่เกี่ยวข้องทั้งหมดด้วยตัวสร้างที่ให้มาและใช้ในโค้ดของคุณแทนการนำเข้าโดยตรงจากแพ็คเกจreact-redux:

เป้าหมายระยะยาวของเราคือการลบ Redux ออกจากโปรเจ็กต์ Dashboard โดยสิ้นเชิง และลบ Redux "เก่า" ออกจากโปรเจ็กต์ Studio เรากำลังมุ่งสู่เป้าหมายนี้โดยการปรับโครงสร้างไฟล์ทุกไฟล์ที่เราต้องสัมผัส ในขณะที่พัฒนาคุณสมบัติใหม่และแก้ไขข้อบกพร่อง

การเปลี่ยนผ่านทางเทคนิคที่สำคัญเหล่านี้ต้องราบรื่นและเพิ่มขึ้นโดยส่วนใหญ่ด้วยเหตุผลสองประการ ประการแรก คุณกำลังยกเครื่องชีวิตการทำงานในแต่ละวันของทีม พวกเขาควรยินดีกับการเปลี่ยนแปลงเหล่านี้ มิฉะนั้นประสิทธิภาพจะลดลงอย่างมาก ในทางกลับกัน ถ้าพวกเขาชอบเครื่องมือที่พวกเขาใช้สร้างและบอกว่าเครื่องมือช่วยพวกเขาแทนที่จะปิดกั้น ประสิทธิภาพของพวกเขาก็จะเพิ่มขึ้นอย่างมาก และประการที่สอง ผลิตภัณฑ์จะต้องสร้างต่อไป การแสดงต้องดำเนินต่อไป. จะต้องมีคุณสมบัติใหม่ๆ มันจำเป็นต้องก้าวไปข้างหน้า ดังนั้นการเปลี่ยนทางเทคนิคจึงต้องไม่ขัดขวางการพัฒนาผลิตภัณฑ์ ทุกการเปลี่ยนแปลงควรเพิ่มขึ้น

สรุป

เมื่อตัดสินใจทางเทคนิคในฐานะนักพัฒนา เราควรพิจารณาทุกแง่มุมของโครงการที่เรากำลังดำเนินการและความต้องการของทีมที่เรากำลังทำงานด้วย นั่นเป็นเพียงเพราะการตัดสินใจทางเทคนิคเหล่านี้ส่งผลกระทบต่อทีมและทุกคนที่ทำงานในโครงการ ไม่ใช่แค่นักพัฒนา

การเปลี่ยนแปลงทางเทคนิคควรเพิ่มขึ้นโดยมีค่าใช้จ่ายทั้งหมด การเปลี่ยนแปลงเหล่านี้ไม่ควรปิดกั้นไปป์ไลน์ของผลิตภัณฑ์ และดังนั้นจึงเป็นความสำเร็จ

และจำไว้เสมอว่า เพื่อให้นักพัฒนาทำงานได้อย่างมีประสิทธิภาพ คุณต้องมอบเครื่องมือที่ทำให้พวกเขามีความสุข