เหตุใดจึงต้องใช้ Redux บน Facebook Flux [ปิด]

ฉันได้อ่านคำตอบนี้ , ลดสำเร็จรูปมองที่ GitHub ตัวอย่างไม่กี่และแม้กระทั่งพยายาม Redux นิด ๆ หน่อย ๆ (ปพลิเคชันที่ต้องทำ)

ดังที่ฉันเข้าใจแรงจูงใจ doc redux ทางการให้ข้อดีเมื่อเปรียบเทียบกับสถาปัตยกรรม MVC แบบดั้งเดิม แต่มันไม่ได้ให้คำตอบสำหรับคำถาม:

ทำไมคุณควรใช้ Redux บน Facebook Flux

นั่นเป็นเพียงคำถามของสไตล์การเขียนโปรแกรม: functional vs non-functional หรือไม่? หรือคำถามอยู่ในความสามารถ / เครื่องมือ dev ที่ตามมาจากวิธีการ redux? อาจจะปรับขนาด? หรือทดสอบ?

ฉันพูดถูกหรือไม่ถ้าฉันบอกว่า redux เป็นฟลักซ์สำหรับผู้ที่มาจากภาษาที่ใช้งานได้

เพื่อตอบคำถามนี้คุณอาจเปรียบเทียบความซับซ้อนของการใช้คะแนนแรงจูงใจของ redux กับ flux และ redux

นี่คือจุดจูงใจจากแรงจูงใจ doc redux ทางการ :

1. การจัดการกับการปรับปรุงในแง่ดี ( อย่างที่ฉันเข้าใจมันแทบจะไม่ขึ้นอยู่กับจุดที่ 5 มันยากที่จะใช้มันใน facebook flux หรือไม่ )
2. การแสดงผลบนเซิร์ฟเวอร์ ( ฟลักซ์ Facebook ยังสามารถทำสิ่งนี้ได้ประโยชน์ใด ๆ เมื่อเทียบกับการลักซ์ )
3. การดึงข้อมูลก่อนที่จะทำการเปลี่ยนเส้นทาง ( เหตุใดจึงไม่สามารถทำได้ใน facebook flux มีประโยชน์อย่างไร )
4. โหลดซ้ำร้อน ( เป็นไปได้ด้วยReact Hot Reloadเราต้องใช้ redux ทำไม )
5. เลิกทำ / ทำซ้ำฟังก์ชั่น
6. ประเด็นอื่น ๆ ? ชอบสถานะที่ยังคงอยู่ ...

เขียน Redux ที่นี่!

Redux ไม่ได้ว่าแตกต่างจากฟลักซ์ โดยรวมแล้วมันมีสถาปัตยกรรมเดียวกัน แต่ Redux สามารถตัดมุมซับซ้อนบางส่วนได้โดยใช้การจัดองค์ประกอบการทำงานที่ Flux ใช้การลงทะเบียนการโทรกลับ

ไม่มีความแตกต่างพื้นฐานใน Redux แต่ฉันพบว่ามันทำให้บาง abstractions ง่ายขึ้นหรืออย่างน้อยก็เป็นไปได้ที่จะนำมาใช้ซึ่งจะยากหรือเป็นไปไม่ได้ที่จะนำไปใช้ใน Flux

องค์ประกอบลด

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

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

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

เซิร์ฟเวอร์แสดงผล

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

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

ยังคงมีปัญหาต่อไปนี้ที่คุณต้องแก้ไขใน Flux (ด้วยตัวคุณเองหรือด้วยความช่วยเหลือของ Flux library ที่คุณโปรดปรานเช่นFlummoxหรือAlt ):

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

กรอบ Flux ที่เป็นที่ยอมรับ (ไม่ใช่ vanilla Flux) มีวิธีแก้ไขปัญหาเหล่านี้ แต่ฉันพบว่ามันซับซ้อนเกินไป ยกตัวอย่างเช่นFlummox ขอให้คุณในการดำเนินการserialize()และdeserialize()ในร้านค้าของคุณ Alt แก้ปัญหา nicer นี้โดยการจัดเตรียมtakeSnapshot()สถานะของคุณให้เป็นลำดับโดยอัตโนมัติในทรี JSON

Redux เดินหน้าต่อไป: เนื่องจากมีเพียงร้านเดียว (จัดการโดย reducers จำนวนมาก), คุณไม่จำเป็นต้องมี API พิเศษใด ๆ ในการจัดการกับ hydration (re) คุณไม่จำเป็นต้อง "ร้านค้า" ล้าง "หรือ" ไฮเดรต "- มีเพียงร้านเดียวและคุณสามารถอ่านสถานะปัจจุบันของมันหรือสร้างร้านค้าใหม่ด้วยสถานะใหม่ คำขอแต่ละรายการจะได้รับอินสแตนซ์ร้านค้าแยกต่างหาก อ่านเพิ่มเติมเกี่ยวกับการแสดงผลเซิร์ฟเวอร์ด้วย Redux

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

ประสบการณ์นักพัฒนา

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

ฉันไม่ได้เห็นห้องสมุด Flux เดียวที่สามารถทำได้ React Hot Loader ไม่อนุญาตให้คุณทำเช่นนี้ - จริง ๆ แล้วมันจะแตกถ้าคุณแก้ไข Flux stores เพราะมันไม่รู้ว่าต้องทำอะไรกับมัน

เมื่อ Redux ต้องการโหลดรหัสลดใหม่จะมีการเรียกใช้replaceReducer()และแอปจะทำงานด้วยรหัสใหม่ ใน Flux ข้อมูลและฟังก์ชั่นจะพันกันในร้านค้า Flux ดังนั้นคุณจึงไม่สามารถ“ แค่แทนที่ฟังก์ชั่น” ได้ ยิ่งไปกว่านั้นคุณจะต้องลงทะเบียนเวอร์ชั่นใหม่ด้วย Dispatcher อีกครั้ง - สิ่งที่ Redux ไม่ได้มี

ระบบนิเวศ

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

ความง่าย

Redux รักษาผลประโยชน์ทั้งหมดของ Flux (การบันทึกและการเล่นซ้ำของการกระทำการไหลของข้อมูลทิศทางเดียวการกลายพันธุ์ที่ขึ้นอยู่กับ) และเพิ่มผลประโยชน์ใหม่ (ยกเลิกการทำซ้ำง่ายการโหลดซ้ำร้อน) โดยไม่ต้องแนะนำ

การทำให้เป็นเรื่องง่ายนั้นเป็นสิ่งสำคัญเพราะมันทำให้คุณมีสติในขณะที่คุณใช้ abstractions ระดับที่สูงขึ้น

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

คุณสามารถอ่านและทำความเข้าใจกับ Redux ได้ทั้งหมด

ดูเพิ่มเติมคำตอบของฉันในข้อเสียของการใช้ Redux เมื่อเทียบกับฟลักซ์

ใน Quora บางคนพูดว่า :

ก่อนอื่นมันเป็นไปได้ทั้งหมดที่จะเขียนแอพด้วย React without Flux

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

แต่ถ้าคุณยังสนใจรู้เพิ่มเติมอ่านต่อ

ฉันเชื่อว่าคุณควรเริ่มต้นด้วยปฏิกิริยาที่แท้จริงจากนั้นเรียนรู้ Redux และ Flux หลังจากที่คุณได้รับประสบการณ์จริงกับ React แล้วคุณจะเห็นว่า Redux มีประโยชน์สำหรับคุณหรือไม่

บางทีคุณอาจรู้สึกว่า Redux เหมาะกับแอปของคุณและคุณอาจจะรู้ว่า Redux กำลังพยายามแก้ปัญหาที่คุณไม่ได้ประสบ

หากคุณเริ่มต้นโดยตรงกับ Redux คุณอาจจบลงด้วยรหัส over-engineered รหัสยากที่จะรักษาและมีข้อบกพร่องมากขึ้นและโดยไม่ต้อง Redux

จากRedux docs :

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

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

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

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

ตามมาด้วยเสียงฝีเท้าของ Flux, CQRS และ Event Sourcing, Redux พยายามทำให้การกลายพันธุ์ของรัฐสามารถคาดการณ์ได้โดยกำหนดข้อ จำกัด บางอย่างเกี่ยวกับวิธีและเวลาที่การอัพเดทสามารถเกิดขึ้นได้ ข้อ จำกัด เหล่านี้สะท้อนให้เห็นในหลักการสามข้อของ Redux

รวมทั้งจากRedux docs :

แนวคิดหลัก
Redux นั้นง่ายมาก

ลองนึกภาพสถานะแอปของคุณอธิบายว่าเป็นวัตถุธรรมดา ตัวอย่างเช่นสถานะของแอพสิ่งที่ต้องทำอาจมีลักษณะเช่นนี้:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

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

ในการเปลี่ยนบางสิ่งในสถานะคุณจำเป็นต้องจัดส่งการกระทำ การกระทำเป็นวัตถุ JavaScript ธรรมดา (สังเกตว่าเราไม่ได้ใช้เวทมนตร์หรือไม่) ที่อธิบายสิ่งที่เกิดขึ้น นี่คือตัวอย่างการกระทำ:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

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

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

และเราเขียนตัวลดอื่นที่จัดการสถานะสมบูรณ์ของแอพของเราโดยการเรียกสองตัวลดขนาดเพื่อหารหัสสถานะที่สอดคล้องกัน:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

นี่คือแนวคิดทั้งหมดของ Redux โปรดทราบว่าเราไม่ได้ใช้ Redux API ใด ๆ มาพร้อมกับยูทิลิตี้เล็กน้อยเพื่ออำนวยความสะดวกในรูปแบบนี้ แต่แนวคิดหลักคือคุณอธิบายว่าสถานะของคุณได้รับการปรับปรุงอย่างไรเมื่อเวลาผ่านไปเพื่อตอบสนองต่อวัตถุการกระทำและ 90% ของรหัสที่คุณเขียนนั้นเป็นเพียง JavaScript ธรรมดาโดยไม่ต้องใช้ Redux ตัวเอง APIs หรือเวทมนตร์ใด ๆ

คุณอาจเริ่มต้นด้วยการอ่านโพสต์นี้โดย Dan Abramov ที่เขาพูดถึงการนำ implement ของ Flux ไปใช้และการแลกเปลี่ยนของพวกเขาในขณะที่เขาเขียน redux: The Evolution of Flux Frameworks

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

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

ฉันเป็นผู้เริ่มแรกและใช้แอปพลิเคชั่นหน้าเดียวขนาดกลางถึงขนาดใหญ่โดยใช้ห้องสมุด Facebook Flux

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

ฉันขอแนะนำให้คุณเล่นกับมันเพราะมันแสดงให้เห็นถึงการทำงานภายในของสถาปัตยกรรม Flux ที่ค่อนข้างเป็นทางการศึกษา แต่ในขณะเดียวกันมันก็ไม่ได้ให้ประโยชน์มากมายเท่าที่ห้องสมุดเช่น Redux จัดหาให้ (ซึ่งไม่ใช่ สำคัญสำหรับโครงการขนาดเล็ก แต่มีค่ามากสำหรับโครงการที่ใหญ่กว่า)

เราได้ตัดสินใจแล้วว่าการก้าวไปข้างหน้าเราจะย้ายไปที่ Redux และฉันขอแนะนำให้คุณทำเช่นเดียวกัน;)

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

สำหรับข้อมูลเพิ่มเติมFlux vs Redux

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

จากตัวรับปฏิกิริยาใหม่ / ผู้เปลี่ยนใจจากการโยกย้ายจาก (ไม่กี่ปี) ExtJS ในช่วงกลางปี ​​2018:

หลังจากเลื่อนย้อนกลับไปสู่ช่วงโค้งการเรียนรู้ของ Redux ฉันมีคำถามเดียวกันและคิดว่าฟลักซ์บริสุทธิ์จะง่ายกว่าเช่น OP

ในไม่ช้าฉันก็เห็นประโยชน์ของการเปลี่ยนถ่ายภาพฟลักซ์ตามที่ระบุไว้ในคำตอบข้างต้นและทำงานเป็นแอปแรกของฉัน

ขณะที่ได้รับการจับบนจานหม้อไอน้ำอีกครั้งผมพยายามออกบางส่วนของอื่น ๆ libs การจัดการของรัฐที่ดีที่สุดที่ฉันพบคือการแข่งขัน

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

นอกจากนี้ยังทำงานด้วยเครื่องมือการเปลี่ยนสีเดียวกัน นี่เป็นบทความที่ดีที่ครอบคลุมประโยชน์บางประการ

ดังนั้นสำหรับคนอื่น ๆ ที่มาถึงโพสต์ SO ดังนั้นการค้นหา "redux ที่ง่ายกว่า" ฉันขอแนะนำให้ลองใช้มันเป็นทางเลือกที่ง่ายในการ redux พร้อมผลประโยชน์ทั้งหมดและ 1/4 ของสำเร็จรูป

อ้างอิงจากบทความนี้: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

คุณควรใช้ MobX เพื่อจัดการข้อมูลในแอปของคุณเพื่อให้ได้ประสิทธิภาพที่ดีขึ้นไม่ใช่ Redux