Redux คืออะไร: คู่มือสำหรับนักออกแบบ

คุณเคยได้ยินเกี่ยวกับ Redux หรือไม่? มันคืออะไร? ไม่มี googling ได้โปรด!

• “สิ่งเบื้องหลังแฟนซี”
• “ฉันเคยได้ยินเรื่องนี้ แต่ฉันไม่รู้ว่ามันคืออะไร อาจเป็นกรอบ React หรือเปล่า”
• “วิธีที่ดีกว่าในการจัดเก็บและจัดการสถานะในแอปพลิเคชัน React”

ฉันได้ถามคำถามนี้กับนักออกแบบกว่า 40 คน ข้างต้นเป็นคำตอบทั่วไปของพวกเขา หลายคนทราบดีว่า Redux ทำงานร่วมกับ React และหน้าที่ของมันคือ "การจัดการสถานะ"

แต่คุณรู้หรือไม่ว่า "การจัดการของรัฐ" นี้หมายถึงอะไรจริงๆ? คุณรู้หรือไม่ว่าอำนาจที่แท้จริงของ Redux อยู่เหนือการจัดการสถานะ? คุณรู้หรือไม่ว่า Redux ไม่ต้องการ React เพื่อทำงาน คุณต้องการเข้าร่วมการสนทนาของทีมของคุณ (หรืออย่างน้อยก็พูดคุยระหว่างรับประทานอาหารกลางวัน) เกี่ยวกับว่าจะใช้ Redux หรือไม่ คุณต้องการออกแบบด้วยความเข้าใจว่า Redux ทำงานอย่างไร?

ด้วยความช่วยเหลือของบทความนี้ ฉันต้องการแสดงภาพรวมของ Redux ให้คุณเห็น : สิ่งที่สามารถทำได้ ทำไมมันถึงทำสิ่งต่าง ๆ ของมัน ข้อเสียคืออะไร เมื่อใดจึงจะใช้งาน และความเกี่ยวข้องกับการออกแบบอย่างไร

เป้าหมายของฉันคือการช่วยนักออกแบบเช่นคุณ แม้ว่าคุณจะไม่เคยเขียนโค้ดบรรทัดเดียวมาก่อน แต่ฉันคิดว่ามันยังคงเป็นไปได้และเป็นประโยชน์ (และสนุก) ที่จะเข้าใจ Redux คาดหวังภาษาอังกฤษและ doodle แบบธรรมดา — ไม่มีโค้ดหรือคำพูดที่เป็นนามธรรม

พร้อมสำหรับการนั่ง?

Redux คืออะไร?

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

ทำไมคุณควรดูแล?

Redux เป็นเรื่องเกี่ยวกับการทำงานภายในของแอปมากกว่ารูปลักษณ์และความรู้สึกของแอป เป็นเครื่องมือที่ค่อนข้างซับซ้อนและมีช่วงการเรียนรู้ที่สูงชัน นั่นหมายความว่าเราในฐานะนักออกแบบควรอยู่ห่างจากมันหรือไม่?

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

“การออกแบบไม่ใช่แค่รูปลักษณ์และความรู้สึกเท่านั้น การออกแบบคือวิธีการทำงาน”

- สตีฟจ็อบส์

Redux ทำอะไรได้บ้าง?

หลายคนใช้ Redux เพื่อจัดการสถานะในแอป React เป็นกรณีการใช้งานทั่วไปใน wild และ Redux ปรับปรุงด้านที่ React ทำได้ไม่ดี (ยัง)

อย่างไรก็ตาม ในไม่ช้า คุณจะเห็นว่าพลังที่แท้จริงของ Redux ไปไกลกว่านั้น เริ่มต้นด้วยการเรียนรู้ว่าการจัดการของรัฐหมายถึงอะไร

การจัดการของรัฐ

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

การจัดการของรัฐหมายถึงอะไร? โดยทั่วไป มีข้อมูลสามประการที่เราจำเป็นต้องจัดการในแอป:

1. การดึงและจัดเก็บข้อมูล
2. การกำหนดข้อมูลให้กับองค์ประกอบ UI
3. กำลังเปลี่ยนข้อมูล

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

อันดับแรก เราต้องดึงข้อมูลทั้งหมดเหล่านี้จากเซิร์ฟเวอร์ในคลาวด์และนำไปไว้ที่ใดที่หนึ่ง ต่อไปเราต้องแสดงข้อมูลจริงๆ เราจำเป็นต้องกำหนดส่วนต่างๆ ของข้อมูลนี้ให้กับองค์ประกอบ UI ที่เกี่ยวข้อง ซึ่งแสดงถึงสิ่งที่เราเห็นจริงในเบราว์เซอร์ ตัวอย่างเช่น เรากำหนด URL ของรูปโปรไฟล์ให้กับแอตทริบิวต์ src ของแท็ก HTML img :

 <img src='https://url/to/profile_photo'>

สุดท้าย เราต้องจัดการกับการเปลี่ยนแปลงข้อมูล ตัวอย่างเช่น หากผู้ใช้เพิ่มความคิดเห็นใหม่ให้กับช็อต Dribbble หรือเพิ่มดาว เราจำเป็นต้องอัปเดต HTML ตามนั้น

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

การดึงและจัดเก็บข้อมูล

ใน React เราแบ่ง UI ออกเป็นส่วนประกอบ แต่ละองค์ประกอบเหล่านี้สามารถแบ่งออกเป็นส่วนประกอบที่มีขนาดเล็กลงได้ (ดู “อะไรคือปฏิกิริยา”)

หาก UI ของเรามีโครงสร้างแบบนี้ เราจะดึงข้อมูลเมื่อใดและจะจัดเก็บไว้ที่ไหนก่อนที่จะสร้าง UI

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

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

วิธีนี้เป็นการสิ้นเปลือง เราจำเป็นต้องเรียกเซิร์ฟเวอร์หลายครั้งจากส่วนประกอบต่างๆ — แม้จะเป็นข้อมูลเดียวกันก็ตาม เชฟจะเปลืองน้ำมันและเวลาในการเดินทางไปมา

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

ร้านยังทำหน้าที่เป็นแหล่งเดียวของความจริง ส่วนประกอบจะดึงข้อมูลจากร้านค้าเสมอ ไม่ใช่จากที่อื่น สิ่งนี้ทำให้เนื้อหา UI ทั้งหมดสอดคล้องกัน

การกำหนดข้อมูลให้กับองค์ประกอบ UI

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

วิธีนี้มีประสิทธิภาพมากกว่าวิธีการดึงข้อมูลจากทุกองค์ประกอบอย่างไร้เดียงสา แต่ Shotwell จะส่งส่วนผสมไปให้เชฟคนอื่นๆ ได้อย่างไร? จะส่งข้อมูลไปยังส่วนประกอบที่แสดงองค์ประกอบ HTML ได้อย่างไร เราส่งข้อมูลจากส่วนประกอบภายนอกไปยังส่วนประกอบภายใน เช่น กระบองในรีเลย์ ไปจนถึงข้อมูลถึงปลายทาง

ตัวอย่างเช่น ต้องส่ง URL ของอวาตาร์ของผู้เขียนจาก "Shot" ถึง "ShotDetail" ถึง "Title" และสุดท้ายไปที่แท็ก <img> หากพ่อครัวของเราอาศัยอยู่ในอพาร์ตเมนต์ จะมีลักษณะดังนี้:

ในการส่งข้อมูลไปยังปลายทาง เราต้องมีส่วนร่วมกับองค์ประกอบทั้งหมดบนเส้นทาง แม้ว่าจะไม่ต้องการข้อมูลเลยก็ตาม จะน่ารำคาญจริง ๆ ถ้ามีหลายชั้น!

จะเกิดอะไรขึ้นถ้าซุปเปอร์สโตร์ทำการจัดส่งแบบ door-to-door? ด้วย Redux ¹ เราสามารถเสียบข้อมูลใดๆ ลงในส่วนประกอบใดๆ ก็ได้ โดยไม่กระทบต่อส่วนประกอบอื่นๆ เลย เช่น:

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

หมายเหตุ : ใน React เวอร์ชันล่าสุด (16.3) มี API "บริบท" ใหม่ที่ทำหน้าที่เกือบจะเหมือนกันในแง่ของการเสียบข้อมูลเข้ากับส่วนประกอบ ดังนั้น หากนี่คือเหตุผลเดียวที่ทีมของคุณใช้ Redux ให้พิจารณาอัปเกรดเป็น React 16.3 อย่างจริงจัง! ตรวจสอบเอกสารอย่างเป็นทางการสำหรับข้อมูลเพิ่มเติม (คำเตือน: รหัสจำนวนมากข้างหน้า)

การเปลี่ยนข้อมูล

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

อาจเป็นเรื่องยากหากเราไม่มีโครงสร้างที่ดีสำหรับตรรกะทั้งหมดนี้ รหัสจะเข้าใจและบำรุงรักษาได้ยาก

Redux ช่วยให้เราสามารถแบ่งและพิชิต . เป็นวิธีมาตรฐานในการแบ่งลอจิกการอัปเดตข้อมูลออกเป็น "ตัวลด" ขนาดเล็ก รีดิวเซอร์เหล่านั้นทำงานร่วมกันอย่างกลมกลืนเพื่อดำเนินการที่ซับซ้อนให้เสร็จสิ้น

จับตาดูการพัฒนาล่าสุดของ React แม้ว่า เช่นเดียวกับ "บริบท" API อาจมี "setState" API ใหม่ใน React เวอร์ชันอนาคต จะช่วยให้แบ่งลอจิกการอัปเดตที่ซับซ้อนออกเป็นส่วนเล็กๆ ได้ง่ายขึ้น เมื่อ API ใหม่นี้พร้อมใช้งาน เป็นไปได้ว่าคุณไม่จำเป็นต้องใช้ Redux อีกต่อไปเพื่อจัดการด้านการจัดการสถานะนี้

พลังที่แท้จริงของ Redux

จนถึงตอนนี้ ดูเหมือนว่า Redux เป็นเพียงวงดนตรีช่วยเหลือสำหรับ React ผู้คนใช้ Redux เพื่อปรับปรุงด้านที่ React ทำได้ไม่ดี (ยัง) แต่ React ก็ตามมาทัน! อันที่จริง Dan Abramov ผู้สร้าง Redux เข้าร่วมทีมหลักของ React ที่ Facebook เมื่อสองสามปีก่อน พวกเขายุ่งอยู่กับการปรับปรุง React: บริบท API (เผยแพร่ใน 16.3), API การดึงข้อมูลที่ดีขึ้น (สาธิตในก.พ. 2018), setState API ที่ดีขึ้นและอื่น ๆ

มันจะทำให้ Redux ล้าสมัยหรือไม่

คาดเดาอะไร? ฉันยังไม่ได้แสดงให้คุณเห็นถึงพลังที่แท้จริงของ Redux!

Redux บังคับให้นักพัฒนาปฏิบัติตามกฎที่เข้มงวดสองสามข้อ ซึ่งทำให้ Redux มีพลังมากมาย (ใช่ พลังแห่งวินัย!):

1. ข้อมูลทั้งหมด (สถานะแอปพลิเคชัน) จะต้องอธิบายเป็นข้อความที่ชัดเจน คุณควรจะสามารถจดข้อมูลทั้งหมดด้วยปากกาบนกระดาษ
2. ทุกการกระทำ (การเปลี่ยนแปลงข้อมูล) จะต้องอธิบายเป็นข้อความที่ชัดเจน คุณต้องจดสิ่งที่คุณจะทำก่อนที่จะเปลี่ยนแปลงอะไร คุณไม่สามารถเปลี่ยนข้อมูลโดยไม่ทิ้งเครื่องหมายไว้ กระบวนการนี้เรียกว่า "การส่งการดำเนินการ" ในคำแสลงของ Redux
3. รหัสของคุณที่เปลี่ยนแปลงข้อมูลจะต้องทำงานเหมือนสูตรทางคณิตศาสตร์ จะต้องส่งคืนผลลัพธ์เดียวกันกับอินพุตเดียวกัน สี่เหลี่ยมจัตุรัสของ 4 จะเป็น 16 เสมอ ไม่ว่าคุณจะเรียกใช้กี่ครั้งก็ตาม

เมื่อคุณทำตามกฎเหล่านี้เพื่อสร้างแอพ ความมหัศจรรย์จะเกิดขึ้น มันเปิดใช้งานคุณสมบัติเจ๋ง ๆ มากมายที่ยากหรือแพงในการใช้งาน นี่คือตัวอย่างบางส่วน. ²

² ฉันรวบรวมตัวอย่างเหล่านี้จากโพสต์ของ Dan Abramov "คุณอาจไม่ต้องการ Redux" และ "React Beginner Question Thread" ของเขา

ยกเลิกทำซ้ำ

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

เนื่องจาก Redux ต้องการให้อธิบายทุกการกระทำเป็นข้อความที่ชัดเจน การรองรับการเลิกทำ/ทำซ้ำเกือบจะฟรี คำแนะนำในการใช้ undo/redo กับ Redux นั้นพอดีกับหน้าอย่างง่าย

สภาพแวดล้อมการทำงานร่วมกัน

หากคุณกำลังสร้างแอปที่คล้ายกับ Google เอกสารซึ่งมีผู้ใช้หลายคนทำงานร่วมกันในงานที่ซับซ้อน ให้พิจารณาใช้ Redux มันน่าจะช่วยยกน้ำหนักให้คุณได้มาก

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

UI ในแง่ดี

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

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

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

Redux รองรับ UI ในแง่ดีในแบบเดียวกับที่ทำเพื่อเลิกทำและทำซ้ำ ทำให้ง่ายต่อการบันทึก เล่นซ้ำ และย้อนกลับการเปลี่ยนแปลงข้อมูลเมื่อได้รับผลลบจากเซิร์ฟเวอร์

คงอยู่และเริ่มต้นจากสถานะ

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

หากคุณสร้างเกมด้วย Redux คุณแค่ต้องการโค้ดเพิ่มอีกสองสามบรรทัดเพื่อบันทึก/โหลดความคืบหน้าของเกม โดยไม่ต้องเปลี่ยนโค้ดที่เหลือ

ระบบขยายได้จริง

ด้วย Redux คุณต้อง "ส่ง" การดำเนินการเพื่ออัปเดตข้อมูลในแอป ข้อจำกัดนี้ทำให้สามารถเชื่อมต่อกับเกือบทุกแง่มุมของสิ่งที่เกิดขึ้นในแอป

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

การดีบักการเดินทางข้ามเวลา

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

Redux ทำให้ความฝันของนักพัฒนาเป็นจริง Redux DevTools ช่วยให้คุณสามารถจัดการความคืบหน้าของแอปที่ทำงานอยู่เป็นวิดีโอ YouTube ได้โดยการลากตัวเลื่อน!

มันทำงานอย่างไร? จำกฎที่เข้มงวดสามข้อที่ Redux บังคับใช้หรือไม่ นั่นเป็นซอสลับของเวทมนตร์

รายงานข้อผิดพลาดอัตโนมัติ

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

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

นี่คือสิ่งที่จะเกิดขึ้นหากคุณใช้ Redux Bug Reporter มันทำงานอย่างไร? ข้อจำกัด Redux สร้างความมหัศจรรย์

ข้อเสียของ Redux

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

เส้นโค้งการเรียนรู้ที่สูงชัน

Redux มีเส้นโค้งการเรียนรู้ที่ค่อนข้างชัน ต้องใช้เวลาทำความเข้าใจ จดจำ และทำความคุ้นเคยกับรูปแบบของมัน ไม่แนะนำให้เรียนรู้ Redux และ React ในเวลาเดียวกันหากทั้งคู่ยังใหม่สำหรับคุณ

รหัส “หม้อต้ม”

ในหลายกรณี การใช้ Redux หมายถึงการเขียนโค้ดเพิ่มเติม มักจะต้องแตะหลายไฟล์เพื่อให้ฟีเจอร์ง่ายๆ ใช้งานได้ ผู้คนบ่นเกี่ยวกับโค้ด "boilerplate" ที่พวกเขาต้องเขียนด้วย Redux

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

บทลงโทษตามผลงาน

Redux อาจมีผลกระทบต่อประสิทธิภาพเนื่องจากข้อจำกัดที่บังคับใช้ จะเพิ่มค่าใช้จ่ายเล็กน้อยทุกครั้งที่มีการเปลี่ยนแปลงข้อมูล ในกรณีส่วนใหญ่ ไม่ใช่เรื่องใหญ่ และการชะลอตัวนั้นไม่สังเกตเห็นได้ชัด อย่างไรก็ตาม เมื่อมีข้อมูลจำนวนมากในร้านค้าและเมื่อข้อมูลมีการเปลี่ยนแปลงบ่อยครั้ง (เช่น เมื่อผู้ใช้พิมพ์อย่างรวดเร็วบนอุปกรณ์เคลื่อนที่) UI อาจทำงานช้าลง

โบนัส: Redux ไม่ใช่แค่สำหรับ React

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

อย่างไรก็ตาม ที่จริงแล้ว Redux สามารถทำงานกับเฟรมเวิร์กส่วนหน้าใดๆ เช่น Angular, Ember.js หรือแม้แต่ jQuery หรือแม้แต่ vanilla JavaScript ลองหาในกูเกิ้ลดู คุณจะพบสิ่งนี้ นี่ นี่ หรือแม้แต่นี่ แนวคิดทั่วไปของ Redux นำไปใช้ได้ทุกที่!

ตราบใดที่คุณใช้ Redux อย่างชาญฉลาด คุณจะได้รับประโยชน์ในหลาย ๆ สถานการณ์ ไม่ใช่แค่ในแอป React

บทสรุป

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

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

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