นี่เป็นคำถามที่ดีมาก การเปรียบเทียบโลกทั้งสองนั้นยากมาก Rx เป็นพอร์ตของส่วนขยายรีแอคทีฟในภาษาอื่นเช่น C #, Java หรือ JS
โกโก้ที่ทำปฏิกิริยาได้รับแรงบันดาลใจจากฟังก์ชั่นการเขียนโปรแกรมเชิงโต้ตอบแต่ในช่วงหลายเดือนที่ผ่านมาก็ได้รับแรงบันดาลใจจากส่วนขยายปฏิกิริยาเช่นกัน ผลลัพธ์คือเฟรมเวิร์กที่แชร์บางสิ่งกับ Rx แต่มีชื่อที่มีต้นกำเนิดใน FRP
สิ่งแรกที่จะพูดได้ก็คือทั้ง RAC และ RxSwift ไม่ใช่การใช้งานฟังก์ชั่นการเขียนโปรแกรมเชิงโต้ตอบตามนิยามของแนวคิดของ Conal จากจุดนี้ทุกอย่างสามารถลดลงได้ถึงวิธีที่แต่ละเฟรมเวิร์กจัดการกับผลข้างเคียงและองค์ประกอบอื่น ๆ
พูดคุยเกี่ยวกับชุมชนและสิ่งต่าง ๆเกี่ยวกับเมตา :
- RAC เป็นโครงการอายุ 3 ปีที่เกิดใน Objective-C ซึ่งต่อมาถูกส่งไปยัง Swift (พร้อมสะพาน) สำหรับการเปิดตัว 3.0 หลังจากวางงานอย่างต่อเนื่องบน Objective-C
- RxSwift เป็นโครงการเก่าสองสามเดือนและดูเหมือนจะมีแรงผลักดันในชุมชนในขณะนี้ สิ่งหนึ่งที่สำคัญสำหรับ RxSwift คืออยู่ภายใต้องค์กรReactiveXและการใช้งานอื่น ๆ ทั้งหมดทำงานในลักษณะเดียวกันการเรียนรู้วิธีจัดการกับ RxSwift จะทำให้การทำงานกับ Rx.Net, RxJava หรือ RxJS เป็นเรื่องง่าย ของไวยากรณ์ภาษา ฉันจะบอกว่าอยู่บนพื้นฐานของปรัชญาการเรียนรู้ครั้งเดียวใช้ทุกที่
ตอนนี้ถึงเวลาสำหรับสิ่งที่เทคโนโลยี
การผลิต / การสังเกตหน่วยงาน
RAC 3.0 มีเอนทิตีหลัก 2 แห่งSignalและSignalProducerรายการแรกที่เผยแพร่กิจกรรมโดยไม่คำนึงถึงผู้สมัครสมาชิกจะถูกแนบหรือไม่รายการที่สองนั้นต้องการstartสัญญาณ / เหตุการณ์ที่เกิดขึ้นจริง การออกแบบนี้ถูกสร้างขึ้นเพื่อแยกแนวคิดที่น่าเบื่อของการสังเกตร้อนและเย็นซึ่งเป็นแหล่งของความสับสนสำหรับนักพัฒนาจำนวนมาก นี่คือเหตุผลที่แตกต่างกันสามารถลดลงได้วิธีที่พวกเขาจัดการผลข้างเคียง
ใน RxSwift SignalและSignalProducerแปลObservableว่ามันอาจฟังดูสับสน แต่เอนทิตีทั้ง 2 นี้เป็นสิ่งเดียวกันในโลก Rx การออกแบบที่มีObservables ใน RxSwift จะต้องสร้างขึ้นหากพิจารณาว่าร้อนหรือเย็นมันอาจฟังดูซับซ้อนไม่จำเป็น แต่เมื่อคุณเข้าใจวิธีการทำงาน (และอีกครั้งที่ร้อน / เย็น / อบอุ่นนั้นเป็นผลข้างเคียงในขณะที่สมัคร / สังเกต ) พวกเขาสามารถทำให้เชื่อง
ในทั้งสองโลกแนวคิดของการสมัครสมาชิกนั้นเหมือนกันโดยทั่วไปมีความแตกต่างเพียงเล็กน้อยที่ RAC แนะนำและเป็นinterruptionเหตุการณ์เมื่อมีการSignalขายทิ้งก่อนที่กิจกรรมที่เสร็จสมบูรณ์จะถูกส่ง ในการสรุปทั้งคู่มีเหตุการณ์ต่อไปนี้:
Nextเพื่อคำนวณค่าที่ได้รับใหม่Errorเพื่อคำนวณข้อผิดพลาดและดำเนินการสตรีมให้ยกเลิกการสมัครผู้สังเกตการณ์ทั้งหมดCompleteเพื่อทำเครื่องหมายสตรีมว่ายกเลิกการสมัครสมาชิกผู้สังเกตการณ์ทั้งหมดแล้ว
นอกจากนี้ยังมี RAC interruptedที่จะถูกส่งเมื่อSignalถูกกำจัดก่อนที่จะทำอย่างถูกต้องหรือมีข้อผิดพลาด
การเขียนด้วยตนเอง
ใน RAC Signal/ SignalProducerเป็นเอนทิตีแบบอ่านอย่างเดียวไม่สามารถจัดการได้จากภายนอกสิ่งเดียวกันสำหรับObservableRxSwift ในการเปลี่ยนSignal/ SignalProducerเป็นเอนทิตีที่สามารถเขียนได้คุณจะต้องใช้pipe()ฟังก์ชั่นเพื่อส่งคืนรายการที่ควบคุมด้วยตนเอง ในพื้นที่ Rx Subjectนี้เป็นชนิดที่แตกต่างกันเรียกว่า
หากแนวคิดการอ่าน / เขียนฟังดูไม่คุ้นเคยการเปรียบเทียบที่ดีกับFuture/ Promiseสามารถทำได้ Futureเป็นตัวยึดอ่านอย่างเดียวเช่นSignal/ SignalProducerและObservableในมืออื่น ๆ ที่เป็นPromiseสามารถเป็นจริงด้วยตนเองเหมือนและpipe()Subject
schedulers
เอนทิตีนี้คล้ายกันมากในทั้งสองโลกแนวคิดเดียวกัน แต่ RAC เป็นแบบอนุกรมเท่านั้น แต่คุณสมบัติ RxSwift ก็มีตัวกำหนดเวลาพร้อมกันเช่นกัน
ส่วนประกอบ
องค์ประกอบเป็นคุณสมบัติที่สำคัญของการเขียนโปรแกรมปฏิกิริยา เขียนลำธารเป็นสาระสำคัญของกรอบทั้งใน RxSwift พวกเขาจะเรียกว่าลำดับ
เอนทิตีที่สังเกตได้ทั้งหมดใน RxSwift เป็นประเภทObservableTypeดังนั้นเราจึงเขียนอินสแตนซ์ของSubjectและObservableกับตัวดำเนินการเดียวกันโดยไม่ต้องกังวลใด ๆ เพิ่มเติม
พื้นที่แร็คSignalและSignalProducer2 หน่วยงานต่าง ๆ และเราจะต้องliftเกี่ยวกับการที่จะสามารถเขียนสิ่งที่ผลิตกับกรณีของSignalProducer Signalเอนทิตีทั้งสองมีโอเปอเรเตอร์ของตัวเองดังนั้นเมื่อคุณต้องการผสมสิ่งต่าง ๆ คุณต้องแน่ใจว่ามีโอเปอเรเตอร์บางตัวอยู่อีกด้านหนึ่งที่คุณลืมเกี่ยวกับการสังเกตการณ์ที่ร้อน / เย็น
ในส่วนนี้Colin Eberhardtสรุปไว้อย่างดีว่า:
เมื่อมองไปที่ API ปัจจุบันการดำเนินงานของสัญญาณจะเน้นไปที่เหตุการณ์ 'ถัดไป' ซึ่งจะช่วยให้คุณสามารถแปลงค่าข้ามการหน่วงเวลาการรวมและการสังเกตบนเธรดที่แตกต่างกัน ในขณะที่ API ผู้ผลิตสัญญาณส่วนใหญ่เกี่ยวข้องกับวงจรชีวิตของสัญญาณ (เสร็จสมบูรณ์, ข้อผิดพลาด), ด้วยการดำเนินการรวมถึง flatMap, takeUntil และ catch
พิเศษ
RAC ยังมีแนวคิดActionและPropertyอดีตเป็นประเภทเพื่อคำนวณผลข้างเคียงส่วนใหญ่เกี่ยวข้องกับการโต้ตอบของผู้ใช้หลังเป็นที่น่าสนใจเมื่อสังเกตค่าเพื่อดำเนินงานเมื่อมีการเปลี่ยนแปลงค่า ใน RxSwift การActionแปลอีกครั้งเป็นสิ่งObservableนี้แสดงให้เห็นอย่างชัดเจนว่าRxCocoaเป็นการผสานรวมของ Rx primitives สำหรับทั้ง iOS และ Mac RAC Propertyสามารถแปลเป็นVariable(หรือBehaviourSubject) ใน RxSwift
สิ่งสำคัญคือต้องเข้าใจว่าProperty/ Variableเป็นวิธีที่เราเชื่อมโยงโลกที่จำเป็นเข้ากับธรรมชาติของการเขียนโปรแกรมปฏิกิริยาดังนั้นบางครั้งก็เป็นองค์ประกอบพื้นฐานเมื่อต้องจัดการกับห้องสมุดบุคคลที่สามหรือฟังก์ชั่นหลักของพื้นที่ iOS / Mac
ข้อสรุป
RAC และ RxSwift เป็นสัตว์ที่แตกต่างกันสองตัวโดยสิ้นเชิงในอดีตนั้นมีประวัติศาสตร์อันยาวนานในพื้นที่โกโก้และผู้มีส่วนร่วมจำนวนมากหลังนี้ยังอายุน้อย แต่อาศัยแนวคิดที่ได้รับการพิสูจน์แล้วว่ามีประสิทธิภาพในภาษาอื่นเช่น Java, JS หรือ .สุทธิ. การตัดสินใจที่ดีกว่าขึ้นอยู่กับความชอบ RAC ระบุว่าจำเป็นต้องมีการแยกร้อน / เย็นซึ่งเป็นคุณสมบัติหลักของเฟรมเวิร์ก RxSwift กล่าวว่าการรวมกันของพวกมันนั้นดีกว่าการแยกอีกครั้งมันเป็นแค่การจัดการ / ดำเนินการผลข้างเคียง
ดูเหมือนว่า RAC 3.0 จะมีการแนะนำความซับซ้อนที่ไม่คาดคิดไว้บนเป้าหมายหลักของการแยกการสังเกตการณ์แบบร้อน / เย็นเช่นแนวคิดของการหยุดชะงักการแยกตัวดำเนินการระหว่าง 2 เอนทิตีและแนะนำพฤติกรรมที่จำเป็นบางอย่างstartเพื่อเริ่มสร้างสัญญาณ สำหรับบางคนสิ่งเหล่านี้อาจเป็นสิ่งที่ดีที่มีหรือเป็นคุณสมบัตินักฆ่าสำหรับบางคนพวกเขาอาจไม่จำเป็นหรืออันตราย อีกสิ่งที่ต้องจำไว้คือ RAC พยายามที่จะติดตามการประชุมโกโก้ให้มากที่สุดเท่าที่จะเป็นไปได้ดังนั้นหากคุณเป็นนักพัฒนาโกโก้ที่มีประสบการณ์คุณควรรู้สึกสะดวกสบายที่จะทำงานกับมันมากกว่า RxSwift
ในทางกลับกัน RxSwift อาศัยอยู่กับข้อเสียทั้งหมดเช่นข้อสังเกตร้อน / เย็น แต่ยังเป็นสิ่งที่ดีของส่วนขยายปฏิกิริยา การย้ายจาก RxJS, RxJava หรือ Rx.Net ไปยัง RxSwift เป็นสิ่งที่เรียบง่ายแนวคิดทั้งหมดเหมือนกันดังนั้นสิ่งนี้ทำให้การค้นหาเนื้อหาที่น่าสนใจค่อนข้างน่าจะเป็นปัญหาเดียวกับที่คุณเผชิญอยู่ตอนนี้ได้รับการแก้ไขโดยคนใน RxJava และวิธีแก้ปัญหา สามารถนำมาใช้ใหม่โดยคำนึงถึงแพลตฟอร์ม
ต้องเลือกอันไหนเป็นเรื่องของการตั้งค่าแน่นอนจากมุมมองวัตถุประสงค์ไม่สามารถบอกได้ว่าอันไหนดีกว่า วิธีเดียวคือใช้ไฟ Xcode และลองใช้ทั้งคู่และเลือกอันที่รู้สึกสบายกว่าที่จะทำงานด้วย พวกเขามีการใช้งาน 2 แนวคิดที่คล้ายกันพยายามบรรลุเป้าหมายเดียวกัน: ทำให้การพัฒนาซอฟต์แวร์ง่ายขึ้น