ทำความเข้าใจกับรูปแบบฟลักซ์

ฉันกำลังศึกษารูปแบบฟลักซ์และมีบางอย่างที่ฉันไม่สามารถเข้าใจเกี่ยวกับร้านค้าได้

พวกเขาคืออะไรกันแน่

ฉันได้อ่านบทความมากมายและดูเหมือนว่ามันเกี่ยวข้องกับโดเมน

มันหมายความว่านี่เป็นส่วน "นามธรรม" ที่เกี่ยวข้องกับการโทร api หรือการโทรแบ็กเอนด์?

มันไม่ชัดเจนสำหรับฉัน

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

โอเคให้ฉันอธิบายคุณทีละขั้นตอน

1 Flux คืออะไร

• มีลวดลาย
• โปรแกรมเลือกจ่ายส่วนกลาง
• กระแสข้อมูลทิศทางเดียว
• รายการสินค้า

พวกเขาเรียกมันว่าฟลักซ์ด้วยเหตุผลเช่นกัน

การใช้งานฟลักซ์

• ฟลักซ์ของ Facebook
• Alt
• กรดไหลย้อน
• Flummox
• NuclearJS
• Fluxible

แชทกับ Flux

ตอบโต้ : เฮ้แอคชั่นมีคนคลิกที่ปุ่ม "บันทึกหลักสูตร"

การกระทำ : ขอบคุณตอบโต้! ฉันลงทะเบียนผู้สร้างแอคชั่นกับดิสแพตเชอร์ดังนั้นดิสแพตเชอร์ควรดูแลการแจ้งร้านค้าทั้งหมดที่ดูแล

ดิสแพตเชอร์ : ขอดูว่าใครสนใจเรื่องการเรียน อา! ดูเหมือนว่า Store จะลงทะเบียนการติดต่อกลับกับฉันดังนั้นฉันจะแจ้งให้เธอทราบ

ร้านค้า : สวัสดีดิสแพตเชอร์! ขอบคุณสำหรับการอัพเดท! ฉันจะอัปเดตข้อมูลด้วยน้ำหนักบรรทุกที่คุณส่ง ถ้าอย่างนั้นฉันจะปล่อยเหตุการณ์สำหรับองค์ประกอบ React ที่สนใจ

ตอบสนอง : Ooo! ข้อมูลใหม่ที่เป็นประกายจากร้านค้า! ฉันจะอัปเดต UI เพื่อสะท้อนสิ่งนี้!

Flux API

register (ฟังก์ชั่นการโทรกลับ) -“ เฮ้ดิดิสแพตเชอร์เรียกฉันเมื่อมีการกระทำเกิดขึ้น -เก็บ"

ยกเลิกการลงทะเบียน (id สตริง) -“ เฮ้ผู้มอบหมายจ่ายหยุดกังวลเกี่ยวกับการกระทำนี้ -เก็บ"

waitFor (รหัส id) -“ อัปเดตร้านนี้ก่อน -เก็บ"

dispatch (payload object) -“ เฮ้ dispatcher บอกร้านค้าเกี่ยวกับการกระทำนี้ -หนังบู๊"

isDispatching () -“ ฉันไม่ว่างรีบโทรกลับตอนนี้”

ดังนั้นคำถามที่เกิดขึ้นในใจของเราคือ

ดังนั้น Flux เป็นแบบจำลองการสมัครสมาชิกเผยแพร่หรือไม่

ไม่มาก

แตกต่างกันในสองวิธี:

1. น้ำหนักบรรทุกทุกครั้งจะถูกส่งไปยังการเรียกกลับที่ลงทะเบียนทั้งหมด

2. การโทรกลับสามารถรอการเรียกกลับอื่น ๆ

สรุป

Flux เป็นรูปแบบสำหรับการไหลของข้อมูลทิศทางเดียวการดำเนินการห่อหุ้มเหตุการณ์ Dispatcher เป็นฮับส่วนกลางที่เก็บการเรียกกลับร้านค้าเก็บสถานะแอป

ค้นหาตัวอย่างง่ายๆ ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ) "ร้านค้าจะจัดการสถานะแอปพลิเคชันสำหรับโดเมนเฉพาะภายในแอปพลิเคชัน" นั่นคือประกอบด้วย ข้อมูลเกี่ยวกับสถานะของแอปพลิเคชั่นและรหัสทั้งหมดที่จะเปลี่ยน เมื่อใดก็ตามที่มีการอัปเดตใหม่จากโปรแกรมเลือกจ่ายงานร้านค้าทั้งหมดจะเห็นร้านค้าจะทำการตัดสินใจว่าจะอัปเดตข้อมูลของตนอย่างไรจากนั้นพวกเขาจะแจ้งมุมมองว่ามีการเปลี่ยนแปลงข้อมูล ในตัวอย่างร้านค้ามีสิ่งต่าง ๆ เช่น“ รายการเธรดที่มองไม่เห็น” (ที่ดิสแพตเชอร์แจ้งเตือนว่าข้อความใหม่มาถึงหรือเก่าได้ถูกอ่านแล้วและวิวจะแสดงเธรดข้อความไปยังผู้ใช้) และ "เวลาเล่นปัจจุบันและ สถานะ."

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

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