यह एक बहुत अच्छा सवाल है। दोनों दुनिया की तुलना करना बहुत कठिन है। Rx, C #, Java या JS जैसी अन्य भाषाओं में रिएक्टिव एक्सटेंशन्स का एक हिस्सा है।
रिएक्टिव कोकोआ कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग से प्रेरित था , लेकिन पिछले महीनों में, प्रतिक्रियात्मक एक्सटेंशन के साथ- साथ प्रेरित भी बताया गया है । परिणाम एक रूपरेखा है जो आरएक्स के साथ कुछ चीजें साझा करता है, लेकिन एफआरपी में मूल के साथ नाम हैं।
पहली बात यह है कि कॉनल की परिभाषा के अनुसार, न तो RAC और न ही RxSwift कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग कार्यान्वयन हैं । इस बिंदु से सब कुछ कम किया जा सकता है कि कैसे प्रत्येक रूपरेखा साइड इफेक्ट्स और कुछ अन्य घटकों को संभालती है।
चलो समुदाय और मेटा-टेक सामान के बारे में बात करते हैं :
- RAC एक 3 साल पुरानी परियोजना है, जिसका जन्म बाद में Objective-C पर चल रहे काम को पूरी तरह से छोड़ने के बाद Objective-C में 3.0 रिलीज के लिए Swift (पुलों के साथ) में हुआ।
- RxSwift कुछ महीने पुरानी परियोजना है और लगता है कि अभी इस समुदाय में एक गति है। एक चीज़ जो RxSwift के लिए महत्वपूर्ण है, वह है रिएक्टिवएक्स संगठन के तहत और यह कि अन्य सभी कार्यान्वयन उसी तरह से काम कर रहे हैं, RxSwift से कैसे निपटना है, यह सीखना Rx.Net, RxJw या RxJS के साथ काम करना आसान काम है और बस एक बात है भाषा वाक्य रचना की। मैं कह सकता हूँ कि दर्शन पर आधारित है एक बार सीखें, हर जगह लागू करें ।
अब तकनीकी सामान का समय है।
निर्माण / निरीक्षण संस्थाएँ
RAC 3.0 में 2 मुख्य इकाइयाँ हैं, Signalऔर SignalProducer, पहले वाले घटनाओं को प्रकाशित करता है, चाहे कोई ग्राहक संलग्न हो या न हो, दूसरे startको वास्तव में संकेतों / घटनाओं के उत्पादन की आवश्यकता होती है । यह डिजाइन गर्म और ठंडे वेधशालाओं की थकाऊ अवधारणा को अलग करने के लिए बनाया गया है, जो बहुत सारे डेवलपर्स के लिए भ्रम का स्रोत रहा है। यही कारण है कि मतभेदों को कम किया जा सकता है कि वे दुष्प्रभावों का प्रबंधन कैसे करते हैं ।
RxSwift में, Signalऔर SignalProducerअनुवाद करने पर Observable, यह भ्रामक लग सकता है, लेकिन ये 2 इकाइयाँ वास्तव में Rx दुनिया में एक ही बात हैं। ObservableRxSwift में s के साथ एक डिज़ाइन बनाया गया है, जिसमें यह विचार किया जाता है कि क्या वे गर्म या ठंडे हैं, यह अनावश्यक जटिलता के रूप में ध्वनि कर सकता है, लेकिन एक बार जब आप समझ गए कि वे कैसे काम करते हैं (और फिर से गर्म / ठंडा / गर्म है तो सब्सक्राइब / अवलोकन करते समय दुष्प्रभावों के बारे में है। ) उन्हें वश में किया जा सकता है।
दोनों दुनिया में, सदस्यता की अवधारणा मूल रूप से एक ही है, एक छोटा सा अंतर है जिसे आरएसी ने पेश किया है और वह interruptionघटना है जब एक Signalपूरा होने से पहले निपटा दिया गया है। दोनों प्रकार की घटनाओं को फिर से करने के लिए:
Next, नए प्राप्त मूल्य की गणना करने के लिएError, एक त्रुटि की गणना करने और स्ट्रीम को पूरा करने के लिए, सभी पर्यवेक्षकों को बिना बताएComplete, सभी पर्यवेक्षकों को सदस्यता समाप्त करने के रूप में स्ट्रीम को चिह्नित करने के लिए
इसके अलावा RAC interruptedको भेजा जाता है जब Signalसही ढंग से या त्रुटि के साथ पूरा करने से पहले निपटाया जाता है।
मैन्युअल रूप से लेखन
RAC में, Signal/ SignalProducerकेवल पढ़ने वाली Observableइकाइयाँ हैं , उन्हें बाहर से प्रबंधित नहीं किया जा सकता है, यही बात RxSwift में है। एक चालू करने के लिए Signal/ SignalProducerएक लेख में सक्षम इकाई में, आप का उपयोग करने के pipe()समारोह एक मैन्युअल रूप से नियंत्रित सामग्री वापस करने का। आरएक्स स्पेस पर, यह एक अलग प्रकार कहा जाता है Subject।
यदि पढ़ने / लिखने की अवधारणा अपरिचित लगती है, तो Future/ के साथ एक अच्छा सादृश्य Promiseबनाया जा सकता है। A Futureएक रीड-ओनली प्लेसहोल्डर है, जैसे Signal/ SignalProducerऔर Observable, दूसरी ओर, एक Promiseमैन्युअल रूप से, जैसे pipe()और के लिए पूरा किया जा सकता है Subject।
शेड्यूलर
यह इकाई दोनों दुनिया में समान अवधारणाओं के समान है, लेकिन RAC केवल धारावाहिक है, इसके बजाय RxSwift सुविधाएँ समवर्ती शेड्यूलर भी हैं।
रचना
रचना रिएक्टिव प्रोग्रामिंग की प्रमुख विशेषता है। धाराओं की रचना करना दोनों रूपरेखाओं का सार है, RxSwift में उन्हें अनुक्रम भी कहा जाता है ।
RxSwift के सभी नमूदार संस्थाओं प्रकार के होते हैं ObservableType, तो हम के उदाहरण रचना Subjectऔर Observableएक ही ऑपरेटरों के साथ, किसी भी अतिरिक्त चिंता के बिना।
आरएसी अंतरिक्ष पर, Signalऔर SignalProducer2 अलग संस्थाओं कर रहे हैं और हमारे पास करने के लिए liftपर SignalProducerरचना के लिए क्या के उदाहरण के साथ उत्पादन किया जाता है सक्षम होने के लिए Signal। दो संस्थाओं के पास अपने स्वयं के ऑपरेटर हैं, इसलिए जब आपको चीजों को मिलाने की आवश्यकता होती है, तो आपको यह सुनिश्चित करना होगा कि एक निश्चित ऑपरेटर उपलब्ध है, दूसरी तरफ आप गर्म / ठंडे वेधशालाओं के बारे में भूल जाते हैं।
इस भाग के बारे में, कॉलिन एबरहार्ट ने इसे अच्छी तरह से अभिव्यक्त किया:
वर्तमान एपीआई को देखते हुए सिग्नल ऑपरेशन मुख्य रूप से 'अगली' घटना पर केंद्रित होते हैं, जिससे आप विभिन्न थ्रेड्स पर मान, स्किप, विलंब, संयोजन और निरीक्षण कर सकते हैं। जबकि सिग्नल प्रोड्यूसर एपीआई ज्यादातर सिग्नल लाइफसाइकल इवेंट्स (पूर्ण, त्रुटि) से संबंधित है, तब, फ्लैट मैप, टेक यूटिल और कैच सहित संचालन के साथ।
अतिरिक्त
आरएसी की अवधारणा भी है Actionऔर Property, पूर्व साइड इफेक्ट्स की गणना करने के लिए एक प्रकार है, मुख्य रूप से उपयोगकर्ता इंटरैक्शन से संबंधित है, बाद वाला दिलचस्प है जब किसी कार्य को करने के लिए एक मान का निरीक्षण किया जाता है जब मूल्य बदल गया है। RxSwift में Actionअनुवादों को फिर से एक में Observable, यह अच्छी तरह से दिखाया गया है RxCocoa, दोनों iOS और मैक के लिए Rx आदिम का एकीकरण। RAC का RxSwift में Propertyअनुवाद किया जा सकता है Variable(या BehaviourSubject)।
यह समझना महत्वपूर्ण है कि Property/ Variableजिस तरह से हमें प्रतिक्रियाशील प्रोग्रामिंग की घोषणात्मक प्रकृति के लिए अनिवार्य दुनिया को पाटना है, इसलिए कभी-कभी एक मौलिक घटक होता है जब आईओएस / मैक स्थान के तीसरे पक्ष के पुस्तकालयों या मुख्य कार्यात्मकताओं से निपटते हैं।
निष्कर्ष
RAC और RxSwift 2 पूर्ण भिन्न जानवर हैं, पूर्व में कोको स्थान में एक लंबा इतिहास है और बहुत सारे योगदानकर्ता हैं, बाद वाला काफी युवा है, लेकिन उन अवधारणाओं पर निर्भर करता है जो जावा, जेएस या अन्य भाषाओं में प्रभावी साबित हुई हैं। नेट। जो निर्णय बेहतर है वह वरीयता पर है। RAC बताता है कि गर्म / ठंडा देखने योग्य का पृथक्करण आवश्यक था और यही फ्रेमवर्क की मुख्य विशेषता है, RxSwift का कहना है कि उनका एकीकरण पृथक्करण से बेहतर है, फिर से यह है कि कैसे साइड इफेक्ट्स का प्रबंधन / प्रदर्शन किया जाता है।
लगता है कि आरएसी 3.0 ने गर्म / ठंडे वेधशालाओं को अलग करने के प्रमुख लक्ष्य के ऊपर कुछ अप्रत्याशित जटिलता पेश की है, जैसे रुकावट की अवधारणा, 2 संस्थाओं के बीच संचालकों को विभाजित करना और कुछ अनिवार्य व्यवहार startशुरू करना जैसे संकेतों का उत्पादन शुरू करना। कुछ लोगों के लिए ये चीजें एक अच्छी बात हो सकती हैं या यहां तक कि एक हत्यारा सुविधा भी, कुछ अन्य लोगों के लिए वे सिर्फ अनावश्यक या खतरनाक भी हो सकते हैं। याद रखने वाली एक और बात यह है कि आरएसी जितना संभव हो सके कोको सम्मेलनों को बनाए रखने की कोशिश कर रहा है, इसलिए यदि आप एक अनुभवी कोको देव हैं, तो आपको RxSwift के बजाय इसके साथ काम करने में अधिक सहज महसूस करना चाहिए ।
दूसरी ओर RxSwift सभी डाउनसाइड्स जैसे हॉट / कोल्ड ऑब्जर्वबल्स के साथ रहती है, लेकिन रिएक्टिव एक्सटेंशन्स की अच्छी चीजें भी। RxJS, RxJava या Rx.Net से RxSwift पर जाना एक साधारण बात है, सभी अवधारणाएं समान हैं, इसलिए यह सामग्री को काफी रोचक बनाती है, हो सकता है कि अब आप जिस समस्या का सामना कर रहे हैं, वह RxJava और समाधान में किसी के द्वारा हल की गई हो। मंच को ध्यान में रखते हुए फिर से लागू किया जा सकता है।
किसी एक को चुना जाना निश्चित रूप से प्राथमिकता का विषय है, उद्देश्य से, यह बताना असंभव है कि कौन सा बेहतर है। एकमात्र तरीका यह है कि Xcode को आग लगाई जाए और उन दोनों को आज़माएं और जिस काम को करने के लिए अधिक सहज महसूस करते हैं उसे चुनें। वे समान अवधारणाओं के 2 कार्यान्वयन हैं, एक ही लक्ष्य को प्राप्त करने की कोशिश कर रहे हैं: सॉफ्टवेयर विकास को सरल बनाना।