Redux - หลายร้านทำไมไม่ทำอย่างนั้น?

ตามที่ทราบ: ฉันได้อ่านเอกสารสำหรับ Redux (Baobab ด้วย) และฉันได้ทำส่วนแบ่งที่ยุติธรรมของ Googling & test

ทำไมจึงแนะนำอย่างยิ่งว่าแอป Redux มีเพียงร้านเดียว?

ฉันเข้าใจข้อดี / ข้อเสียของการตั้งค่าแบบ Single-store และการตั้งค่าแบบหลายสาขา ( มีคำถาม & คำตอบมากมายในเรื่องนี้ )

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

แก้ไข: ข้อเสนอแนะหลังจากแปลงเป็นร้านค้าเดียว

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

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

• มันน่าเชื่อถือ : เราใช้ตัวเลือกเพื่อขุดผ่านสถานะแอพและรับข้อมูลที่เกี่ยวข้องกับบริบท เรารู้ว่าข้อมูลที่จำเป็นทั้งหมดอยู่ในร้านเดียว มันหลีกเลี่ยงการตั้งคำถามทั้งหมดว่าประเด็นปัญหาของรัฐจะอยู่ที่ไหน
• มันเร็ว : ร้านค้าของเรามี 100 reducers ใกล้ถ้าไม่มาก แม้ในจำนวนนั้นมีเพียง reducers เพียงเล็กน้อยเท่านั้นที่ประมวลผลข้อมูลในการแจกจ่ายใด ๆ ที่ได้รับ แต่ผู้อื่นเพียงแค่คืนสถานะก่อนหน้า อาร์กิวเมนต์ที่ร้านค้าขนาดใหญ่ / ซับซ้อน ( nbr of reducers ) ช้านั้นเป็นสิ่งที่สงสัย อย่างน้อยเราไม่เคยเห็นปัญหาเรื่องประสิทธิภาพที่มาจากที่นั่น
• การดีบักที่เป็นมิตร : ในขณะที่นี่เป็นข้อโต้แย้งที่น่าเชื่อถือที่สุดในการใช้ redux โดยรวม แต่ก็มีสำหรับร้านค้าเดี่ยวและร้านค้าหลายแห่ง เมื่อสร้างแอปที่คุณถูกผูกไว้ว่ามีข้อผิดพลาดสถานะในกระบวนการ ( โปรแกรมเมอร์ผิดพลาด ) มันเป็นเรื่องปกติ PITA คือเมื่อข้อผิดพลาดเหล่านั้นใช้เวลาหลายชั่วโมงในการดีบัก ขอขอบคุณร้านค้าเดียว ( และ redux-logger ) เราไม่เคยใช้เวลานานกว่าสองสามนาทีในการแก้ไขปัญหาสถานะใด ๆ

ตัวชี้ไม่กี่

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

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

หวังว่าข้อเสนอแนะนี้จะช่วยให้ผู้อื่น

แก้ไข 2 - เครื่องมือร้านค้าที่เป็นประโยชน์

สำหรับผู้ที่สงสัยว่าจะ "จัดการได้ง่าย" ในร้านเดียวซึ่งสามารถซับซ้อนได้อย่างรวดเร็ว มีเครื่องมือที่ช่วยแยกการพึ่งพาโครงสร้าง / ตรรกะของร้านค้าของคุณ

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

ในตอนนั้นฉันไม่ได้รู้จัก Normalizr ฉันก็สร้างบางสิ่งขึ้นมาในบรรทัดเดียวกัน relational-jsonรับ schema และส่งคืนอินเตอร์เฟสแบบอิงตาราง ( เล็กน้อยเหมือนฐานข้อมูล ) ข้อได้เปรียบของ relational-json คือโครงสร้างข้อมูลของคุณอ้างอิงส่วนอื่น ๆ ของข้อมูลของคุณแบบไดนามิก ( เป็นหลักคุณสามารถสำรวจข้อมูลของคุณในทิศทางใดก็ได้เช่นเดียวกับวัตถุ JS ปกติ ) มันยังไม่โตเท่า Normalizr แต่ฉันใช้มันในการผลิตมาหลายเดือนแล้ว

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

ทำไมเราต้องเน้นเรื่องนี้ในเอกสาร? เพราะคนส่วนใหญ่ที่มาจากพื้นหลัง Flux จะถือว่าร้านค้าหลายร้านเป็นทางออกในการสร้างรหัสการปรับปรุงแบบแยกส่วน อย่างไรก็ตาม Redux มีวิธีแก้ปัญหาที่แตกต่างกันในเรื่องนี้: องค์ประกอบลด

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

• การใช้องค์ประกอบตัวลดทำให้ง่ายต่อการใช้ "การอัพเดทที่ต้องพึ่งพา" a la waitForin Flux โดยการเขียนตัวลดที่เรียกตัวลดอื่น ๆ ด้วยตนเองด้วยข้อมูลเพิ่มเติมและตามลำดับที่เฉพาะเจาะจง

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

• ร้านเดียวทำให้ Redux DevTools มีคุณสมบัติการเดินทางข้ามเวลาได้ นอกจากนี้ยังทำให้ส่วนขยายชุมชนเช่น redux-undo หรือ redux-optimist ง่ายเนื่องจากทำงานในระดับลด ไม่สามารถเขียน "เครื่องมือลด" เช่นนี้สำหรับร้านค้า

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

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

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

ตัวอย่างเช่นฉันมักจะปฏิบัติต่อพื้นที่การทำงานทั่วไปต่อไปนี้เป็นแอพแยกต่างหาก:

• ผู้ดูแลระบบ
• แดชบอร์ด Analytics / data vis
• การจัดการการเรียกเก็บเงินและขั้นตอนการสั่งซื้อ
• ทีมบัญชีองค์กร / การจัดการสิทธิ์

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

วิธีที่ดีที่สุดในการจัดการแอพที่มีขนาดใหญ่มากคือการดูแลพวกมันเหมือนองค์ประกอบของแอพขนาดเล็กจำนวนมาก

หากแอปของคุณน้อยกว่า ~ 50k LOC คุณควรเพิกเฉยคำแนะนำนี้และทำตามคำแนะนำของแดนแทน

หากแอปของคุณมีมากกว่า 1 ล้าน LOC คุณควรแยกมินิแอพออกแม้ว่าคุณจะเก็บไว้ใน repo แบบโมโน

การตัดสินใจด้านสถาปัตยกรรมนี้เป็นของผู้พัฒนาแอพตามความต้องการของโครงการ

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

• มันไม่น่าเชื่อถือเพราะบางส่วนของร้านค้าไม่โดดเดี่ยว
• มันไม่มีประสิทธิภาพเพราะคุณกำลังโคลนนิ่งและสำรวจเส้นทางแฮช Trie เมื่อการกลายพันธุ์เพิ่มขึ้นแบบเลขคณิต - ความซับซ้อนเพิ่มขึ้นในเชิงเรขาคณิต คุณไม่สามารถแก้ไขได้โดยการปรับลด reducers, selector, ฯลฯ คุณต้องแยกค่า trie ของคุณ
• เมื่อมันกลายเป็นช้าไม่มีใครต้องการที่จะแยกมันเป็นแอปพลิเคชันแยกต่างหากด้วยร้านค้าแยกต่างหาก ไม่มีใครต้องการใช้จ่ายเงินในการปรับโครงสร้าง ผู้คนมักจะแปลงส่วนประกอบสมาร์ทบางอย่างให้เป็นดัมพ์และนั่นก็คือ คุณรู้หรือไม่ว่าอนาคตกำลังรอนักพัฒนาของ redux พวกเขาจะรักษานรกเหล่านี้
• มันไม่ได้แก้จุดบกพร่องที่เป็นมิตร เป็นการยากที่จะทำการดีบักการเชื่อมต่อระหว่างส่วนต่าง ๆ ของร้านค้า มันยากมากที่จะวิเคราะห์ปริมาณการเชื่อมต่อเหล่านี้

ลองจินตนาการว่าคุณมีร้านค้า redux หลายแห่ง คุณจะหยุดการไหลของข้อมูลทางเดียว คุณจะรู้ได้ทันทีว่ามีการเชื่อมต่อระหว่างร้านค้าจำนวนเท่าใด คุณสามารถทนทุกข์ทรมานจากการเชื่อมต่อเหล่านี้ต่อสู้กับ deps วงกลม ฯลฯ

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

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

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

ทำไมเราไม่สามารถใช้หลาย ๆ ร้านโดยใช้ redux ????

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

ฉันสามารถสร้างร้านค้าหลายร้านได้หรือไม่ ฉันสามารถนำเข้าร้านค้าของฉันโดยตรงและนำไปใช้ในส่วนประกอบของตัวเองได้หรือไม่?

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

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

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

เหตุผลที่ถูกต้องบางประการสำหรับการใช้หลายร้านใน Redux อาจรวมถึง:

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

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

doc อย่างเป็นทางการโดย redux

การมีร้านสาขาหนึ่งใน Redux เป็นสิ่งที่เราต้องการในหลาย ๆ กรณีฉันใช้ Redux และ Flux และเชื่อว่า Redux ทำงานได้ดีขึ้น!

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

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

หากแอปพลิเคชันทั้งหมดได้รับการจัดการอย่างดีร้านหนึ่งอาจเพียงพอที่จะจัดการสถานะแอปพลิเคชันทั้งหมด ...