Reactivecocoa: ReactiveCocoa संगठन में रेक्स को स्थानांतरित करना

को निर्मित 11 अप्रैल 2016 · 15टिप्पणियाँ · स्रोत: ReactiveCocoa/ReactiveCocoa

यह अनौपचारिक रूप से पहले भी सुझाया गया है, आइए इसे औपचारिक रूप देने का प्रयास करें।

क्यों?

खोज योग्यता । रेक्स समुदाय में अच्छी तरह से ज्ञात नहीं है। आप देख सकते हैं कि कुछ पुल अनुरोध/मुद्दे खुलते हैं, जहां उत्तर "यह रेक्स के लिए बेहतर होगा" या "चेक रेक्स" है। इसे ReactiveCocoa org का हिस्सा बनाकर, लोग इसे आसानी से ढूंढ लेंगे, ( संगठन रूट पर नेविगेट करके) और इसे README में जोड़कर।
विश्वसनीयता । किसी प्रोजेक्ट में नई निर्भरता जोड़ते समय, आमतौर पर यह जांचा जाता है कि लेखक कौन है, उसे क्या समर्थन मिलेगा और उसका रखरखाव कितना अच्छा है। इसके पीछे ReactiveCocoa का नाम होने से मदद मिलेगी। बेशक, मैं @neilpa के कौशल और रेक्स की गुणवत्ता के लिए प्रतिज्ञा करता हूं, इतना ही नहीं, मुझे उनके यहां (ReactiveCocoa main repo) और Rex दोनों में किए गए कार्यों के बारे में पता है। मेरा अनुमान है कि अधिकांश उपयोगकर्ता यह नहीं जानते होंगे।
विस्तार । ReactiveCocoa यह सुनिश्चित करने में बहुत ध्यान केंद्रित करता है कि इसका मूल असंबंधित ऑपरेटरों/सुविधाओं से प्रदूषित नहीं है। एक तरफ यह बहुत अच्छा है, क्योंकि यह एपीआई को अव्यवस्थित नहीं करता है और निर्भरता को छोटा रखता है, लेकिन दूसरी ओर एक टन भयानक ऑपरेटरों को छोड़ दिया जाता है। एक बड़ा समूह जिस पर ध्यान नहीं दिया जा रहा है वह है UI एक। हालांकि रिएक्टिवकोको उन्हें पेश करता है, उपयोगकर्ता को उन्हें पुराने उद्देश्य-सी कोड बेस (RACSignal से SignalProducer/Signal) से जोड़ने की जरूरत है। रेक्स के पास पहले से ही काफी अच्छा कैटलॉग है जो निश्चित रूप से ReactiveCocoa org को लाभान्वित करेगा। यह भी इस रेपो में गतिरोध से जुड़ा है। चूंकि यह एक अच्छी जगह पर है (4.1 रिलीज के साथ) मुझे लगता है कि यह आगे बढ़ने का समय है (नए ऑपरेटरों और प्रथम श्रेणी के नागरिक यूआई बाइंड के साथ)।
प्रबंधन करने में आसान । @neilpa पुल अनुरोधों की समीक्षा और विलय करने के लिए एक अच्छा काम कर रहा है, लेकिन बाकी प्रतिक्रियाशीलकोको सदस्यों के साथ बोझ साझा करने से इसमें काफी सुधार होगा।
अगले कदम

खैर, निश्चित रूप से @neilpa और बाकी टीम दोनों को इस पर सहमत होने और रेपो के स्वामित्व को ReactiveCocoa org पर स्थानांतरित करने की आवश्यकता है। यूआरएल के संबंध में, जीथब सभी भारी भारोत्तोलन करता प्रतीत होता है ।

proposal

स्रोत

RuiAAPeres

👍18

सबसे उपयोगी टिप्पणी

@lukaskubanek मैं पहले बिंदु से सहमत हूं, लेकिन मेरे पास मिश्रित राय है:

नामकरण को सुसंगत बनाने के लिए उपसर्ग rex_xxx को rac_xxx में बदलना

हालाँकि यह लगातार नामकरण करता रहेगा, इसे अलग-अलग नामों से रखते हुए, IMHO के कई फायदे हैं:

मैं एक परियोजना की शुरुआत में दोनों libs को शामिल कर सकता हूं यह मानते हुए कि मुझे उन दोनों की आवश्यकता होगी। आखिरकार, जैसे-जैसे परियोजना विकसित होती है, मैं रेक्स के किसी भी ऑपरेटर का उपयोग करना बंद कर सकता हूं। rex_ के लिए परियोजना में एक त्वरित खोज मुझे इसकी पुष्टि करने और इसे एक निर्भरता के रूप में हटाने में मदद करेगी।
यदि एक ऑपरेटर में अजीब व्यवहार होता है, तो मुझे तुरंत पता चल जाता है कि किस प्रोजेक्ट में समस्या को खोलना है (एक प्रश्न या बग होने के नाते)।
यह शुरुआती लोगों को यह समझने में मदद करता है कि कौन से मुख्य ऑपरेटर हैं, जहां से अन्य सभी का निर्माण किया गया है।

RuiAAPeres 17 अप्रैल 2016

👍3

सभी 15 टिप्पणियाँ

मैं रेक्स को रिएक्टिवकोको संगठन में स्थानांतरित करने के पक्ष में हूं। यह एक व्यक्तिगत खेल के मैदान के रूप में शुरू हुआ लेकिन कुछ और उपयोगी में बदल गया। मैं अपने दिन के काम में भी आरएसी का उपयोग नहीं करता, इसलिए समुदाय को स्वामित्व देना समझ में आता है।

ट्रिगर खींचने से पहले मैं जानना चाहता हूं कि @NachoSoto और @mdiep इसके बारे में कैसा महसूस करते हैं।

neilpa 11 अप्रैल 2016

मैं पूरी तरह से अंदर आऊंगा। मैं यह सुनिश्चित करने के लिए पास/त्वरित कोड-समीक्षा (मुझे इसे करने में प्रसन्नता हो रही है) करने का सुझाव दूंगा ताकि यह सुनिश्चित हो सके कि ऑपरेटर/कार्यान्वयन अप-टू-स्टैंडर्ड हैं (मुझे इसमें संदेह नहीं है हालांकि @neilpa को जानने वाला एक सेकंड :)), लेकिन सिर्फ यह सुनिश्चित करने के लिए कि हम:

इस बात से अवगत हैं कि हमें किन ऑपरेटरों को बनाए रखना होगा (संभवतः कुछ को हटाना? आईडीके)।
सुनिश्चित करें कि हम सुधार और खुले मुद्दों के क्षेत्रों की पहचान करते हैं।

NachoSoto 12 अप्रैल 2016

यदि पुस्तकालय को अधिक सुलभ बनाना लक्ष्य है, तो मेरा सुझाव है कि एक अधिक औपचारिक नाम इसमें मदद कर सकता है। जब मैं इसे देखता हूं तो "रेक्स" रिएक्टिवकोको को ध्यान में नहीं लाता है। सुनिश्चित नहीं है कि सही नाम क्या है, लेकिन नाम में "रिएक्टिवकोको" या यहां तक कि सिर्फ "रिएक्टिव" वाला कुछ बेहतर आईएमओ होगा।

tonyarnold 12 अप्रैल 2016

👍2

मैंने वास्तव में रेक्स को नहीं देखा है, लेकिन मुझे रिएक्टिवकोको संगठन के तहत यूआई-केंद्रित पुस्तकालय का विचार पसंद है। रेक्स उस के लिए एक अच्छी शुरुआत की तरह लगता है। 👍 मुझे लगता है कि @NachoSoto को पहले देखना एक अच्छा विचार है।

मुझे लगता है कि हमें सामान्य रूप से आरएसी के लिए कुछ और मुख्य योगदानकर्ताओं को खोजने की जरूरत है। ऐसा लगता है कि सभी को बहुत पतला फैलाया गया है।

mdiep 12 अप्रैल 2016

@tonyarnold जो मदद कर सकता है। मैं

@mdiep मैं सहमत हूँ। फिर भी, रेक्स को दस्तावेज़ीकरण (रीडमे) के मामले में थोड़ा काम करने की ज़रूरत है। हो सकता है कि एक कैटलॉग बनाएं ताकि स्रोत कोड की जांच करने के बजाय लोगों को पता चले कि यह किस प्रकार का UI बाइंड प्रदान करता है। निश्चित रूप से विविध ऑपरेटर भी हैं, जिन्हें भी प्रलेखित किया जाना चाहिए।

मुझे लगता है कि हमें सामान्य रूप से आरएसी के लिए कुछ और मुख्य योगदानकर्ताओं को खोजने की जरूरत है। ऐसा लगता है कि सभी को बहुत पतला फैलाया गया है।

मैं इससे भी सहमत हूं, यहां काफी काम किया जाना है:

खुले मुद्दों को संशोधित करें।
हो सकता है कि उपयोग के और उदाहरण जोड़ें , जैसे कि यह यहां किया गया था और उसके लिए एक दस्तावेज है। मैंने इसे RACNest के साथ करने की कोशिश की है, लेकिन, कोड के स्निपेट के बजाय, एक इंटरैक्टिव प्रोजेक्ट के साथ।
कुछ परित्यक्त परियोजनाओं को बंद या अपडेट करें (जैसे यह , यह और यह )। हो सकता है कि @jspahrsummers हमारे साथ इन परियोजनाओं पर अपना पीओवी साझा कर सके।
संभावित रूप से गति के लिए उठना शुरू करें और कुछ ऐसा ही करें जो RxSwift ने यहां किया था (उदाहरण के लिए हम Alamofire जैसी चीजों के लिए बाइंड बना सकते हैं)। यह काफी मात्रा में काम हो सकता है, लेकिन यह नए लोगों को ढांचे में भी आकर्षित करेगा (मुझे लगता है कि यह एक कारण है कि आरएक्सस्विफ्ट लोकप्रियता में बढ़ रहा है)।

जहां जरूरत है वहां मदद करने में मुझे खुशी है, क्योंकि मैं अपनी वर्तमान नौकरी पर रेक्स और रिएक्टिवकोको का उपयोग कर रहा हूं।

RuiAAPeres 12 अप्रैल 2016

❤3

@RuiAAPeres ने ReactiveCocoa और Rex का उपयोग और प्रचार करने में जबरदस्त प्रयास किया है, मुझे लगता है कि वह एक अच्छा मुख्य योगदानकर्ता हो सकता है। मुझे लगता है कि मौजूदा बाइंडिंग को आधुनिक बनाने के लिए अभी भी बहुत काम करना है, लेकिन नए भी प्रदान करना है और वह इसे हासिल करने के लिए एक अच्छी संपत्ति हो सकता है।

मैं अपनी वर्तमान नौकरी पर ReactiveCocoa और Rex का भी उपयोग कर रहा हूं, इसलिए मैं भी उपलब्ध हूं और मैं जो कुछ भी कर सकता हूं उसमें मदद करने में दिलचस्पी रखता हूं।

dmcrodrigues 12 अप्रैल 2016

❤2

FYI करें, मैंने अपने व्यक्तिगत खेल के मैदान में रेक्स डेमो जोड़ा https://github.com/inamiy/ReactiveCocoaCatalog/pull/8।
वास्तव में अब तक का अच्छा कोड, और मुझे लगता है कि पहले चरण के लिए केवल संगठन में माइग्रेट करना पर्याप्त है: चमक:

inamiy 12 अप्रैल 2016

रेक्स को रिएक्टिवकोको का आधिकारिक हिस्सा बनाना एक अच्छा विचार है। चूंकि स्विफ्ट मुख्य मॉड्यूल में मुख्य कार्यक्षमता को ध्यान में रखते हुए कोड को कई मॉड्यूल में विभाजित करना वास्तव में आसान बनाता है और यूआई-विशिष्ट एक्सटेंशन के लिए दूसरा मॉड्यूल पेश करना निश्चित रूप से समझ में आता है।

मैं निम्नलिखित परिवर्तनों का प्रस्ताव रखूंगा:

यह स्पष्ट करने के लिए Rex का नाम बदलना कि यह ReactiveCocoa का विस्तार है और यह (ज्यादातर) UI के बारे में है (जैसा कि @tonyarnold द्वारा बताया गया है)
नामकरण को सुसंगत बनाने के लिए उपसर्ग rex_xxx को rac_xxx में बदलना

lukaskubanek 14 अप्रैल 2016

@lukaskubanek मैं पहले बिंदु से सहमत हूं, लेकिन मेरे पास मिश्रित राय है:

नामकरण को सुसंगत बनाने के लिए उपसर्ग rex_xxx को rac_xxx में बदलना

मैं एक परियोजना की शुरुआत में दोनों libs को शामिल कर सकता हूं यह मानते हुए कि मुझे उन दोनों की आवश्यकता होगी। आखिरकार, जैसे-जैसे परियोजना विकसित होती है, मैं रेक्स के किसी भी ऑपरेटर का उपयोग करना बंद कर सकता हूं। rex_ के लिए परियोजना में एक त्वरित खोज मुझे इसकी पुष्टि करने और इसे एक निर्भरता के रूप में हटाने में मदद करेगी।
यदि एक ऑपरेटर में अजीब व्यवहार होता है, तो मुझे तुरंत पता चल जाता है कि किस प्रोजेक्ट में समस्या को खोलना है (एक प्रश्न या बग होने के नाते)।
यह शुरुआती लोगों को यह समझने में मदद करता है कि कौन से मुख्य ऑपरेटर हैं, जहां से अन्य सभी का निर्माण किया गया है।

RuiAAPeres 17 अप्रैल 2016

👍3

हमने कोर स्विफ्ट कोड, ओब्ज-सी कोड, और स्विफ्ट <-> ओब्ज-सी ब्रिज को अलग-अलग रेपो (#2807) में ले जाने पर चर्चा की है, इस रेपो को कोको बाइंडिंग के लिए छोड़ दिया है ... इसलिए मुझे लगता है कि हमें रेक्स को स्थानांतरित करना चाहिए आरएसी 5 के रूप में इस भंडार में कोड।

@neilpa @NachoSoto आप क्या सोचते हैं?

mdiep 13 मई 2016

👍2

क्या रिएक्टिवकोको ओबीजेसी एपीआई पर रेक्स और स्विफ्ट बाइंडिंग की निर्भरता को अलग करने के दौरान हटा दिया जाएगा, यानी स्विफ्ट में फिर से लागू किया जाएगा? अन्यथा, विभाजित आईएमओ रखरखाव के अलावा अन्य चीजों में वास्तव में प्रभावी नहीं होगा, क्योंकि स्विफ्ट उपयोगकर्ताओं को अभी भी कुछ ब्रिज विधियों के लिए संपूर्ण ओबीजेसी पुस्तकालय बनाने की आवश्यकता है।

andersio 13 मई 2016

क्या रिएक्टिवकोको ओबीजेसी एपीआई पर रेक्स और स्विफ्ट बाइंडिंग की निर्भरता को अलग करने के दौरान हटा दिया जाएगा, यानी स्विफ्ट में फिर से लागू किया जाएगा?

हां! इसमें निश्चित रूप से कुछ उद्देश्य-सी शामिल होंगे, लेकिन इसमें ReactiveObjC शामिल नहीं होगा।

mdiep 13 मई 2016

इसलिए मुझे लगता है कि हमें रेक्स कोड को इस रिपॉजिटरी में आरएसी 5 के रूप में स्थानांतरित करना चाहिए।

सहमत हैं, लेकिन हमें रेपो इतिहास के बारे में सावधान रहना होगा। हमें उस चाल/रीबेस/विभाजन को प्रबंधित करने के लिए एक योजना तैयार करनी चाहिए जो एक समझदार रेपो इतिहास बनाए रखता है।

neilpa 13 मई 2016

खुले मुद्दों के लिए भी प्रभाव हैं जिनके पास हमारे पास संभावित subtree split विकल्प नहीं है।

neilpa 13 मई 2016

मुझे लगता है कि यह अब हो गया है, #3210 के लिए धन्यवाद!

liscio 20 अक्तू॰ 2016

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Reactivecocoa: ReactiveCocoa संगठन में रेक्स को स्थानांतरित करना

क्यों?

अगले कदम

सबसे उपयोगी टिप्पणी

सभी 15 टिप्पणियाँ

संबंधित मुद्दों