Reactivecocoa: نقل ريكس إلى منظمة الكاكاو التفاعلية

أنا أؤيد نقل Rex إلى منظمة ReactiveCocoa. لقد بدأ كملعب شخصي لكنه تحول إلى شيء أكثر فائدة. أنا أيضًا لا أستخدم RAC في وظيفتي اليومية بعد الآن ، لذا فإن منح الملكية للمجتمع أمر منطقي.

قبل سحب الزناد ، أود أن أعرف كيف يشعر NachoSoto و mdiep حيال ذلك.

سأكون مشاركًا فيه تمامًا. أقترح إجراء مراجعة / تمرير سريع للشفرة (يسعدني القيام بذلك) للتأكد من أن المشغلين / عمليات التنفيذ مطابقة للمعايير (لا أشك في ذلك من أجل ثانية واحدة مع معرفة neilpa على الرغم من :)) ، ولكن فقط للتأكد من أننا:

• ندرك العوامل التي سنحتاج إلى صيانتها (ربما إزالة بعض؟ idk).
• تأكد من تحديد مجالات التحسين والقضايا المفتوحة.

إذا كان الهدف هو تسهيل الوصول إلى المكتبة ، فإنني أقترح أن يكون هناك اسم رسمي أكثر قد يساعد في ذلك. "ريكس" لا يجلب إلى ذهني ReactiveCocoa عندما أراه. لست متأكدًا من الاسم الصحيح ، ولكن شيئًا ما باستخدام "ReactiveCocoa" أو حتى مجرد "Reactive" في الاسم سيكون أفضل IMO.

لم ألق نظرة على Rex حقًا ، لكني أحب فكرة وجود مكتبة تركز على واجهة المستخدم ضمن منظمة ReactiveCocoa. يبدو أن ريكس بداية جيدة لذلك. 👍 أعتقد أن إلقاء نظرة على NachoSoto أولاً هو فكرة رائعة أيضًا.

أعتقد أننا بحاجة إلى إيجاد بعض المساهمين الأساسيين أكثر من أجل RAC بشكل عام. يبدو أن الجميع قد انتشروا بشكل ضئيل للغاية.

tonyarnold يمكن أن يساعد. ✨

mdiep أوافق. ومع ذلك ، يحتاج ريكس إلى القليل من العمل من حيث التوثيق (التمهيدي). ربما أنشئ كتالوجًا حتى يعرف الناس نوع روابط واجهة المستخدم التي يوفرها ، بدلاً من الاضطرار إلى التحقق من الكود المصدري. هناك أيضًا عوامل تشغيل متنوعة ، يجب توثيقها أيضًا.

أعتقد أننا بحاجة إلى إيجاد بعض المساهمين الأساسيين أكثر من أجل RAC بشكل عام. يبدو أن الجميع قد انتشروا بشكل ضئيل للغاية.

أتفق مع هذا أيضًا ، هناك قدر لا بأس به من العمل الذي يتعين القيام به هنا:

1. مراجعة القضايا المفتوحة .
2. ربما تضيف المزيد من الأمثلة على الاستخدام ، مثل ما تم القيام به هنا ويكون لديك مستند لذلك. لقد حاولت القيام بذلك مع RACNest ، ولكن بدلاً من مقتطفات من التعليمات البرمجية ، مع مشروع تفاعلي.
3. قم بإغلاق أو تحديث بعض المشاريع المهجورة (مثل هذا ، هذا و هذا ). ربما يستطيع jspahrsummers أن يشاركنا وجهة نظره في هذه المشاريع.
4. من المحتمل أن تبدأ في التعود على السرعة والقيام بشيء مشابه لما فعلته RxSwift هنا (على سبيل المثال ، يمكننا إنشاء روابط لأشياء مثل Alamofire ). قد يكون هذا قدرًا كبيرًا من العمل ، ولكنه سيجذب أيضًا أشخاصًا جددًا إلى إطار العمل (أعتقد أن هذا هو أحد أسباب زيادة شعبية RxSwift).

يسعدني تقديم المساعدة عند الحاجة ، حيث إنني أستخدم Rex و ReactiveCocoa في وظيفتي الحالية.

لقد بذلRuiAAPeres جهدًا هائلاً في استخدام ReactiveCocoa و Rex وتعزيزهما ، وأعتقد أنه يمكن أن يكون مساهماً أساسياً جيداً. أعتقد أنه لا يزال هناك الكثير من العمل الذي يتعين القيام به لتحديث الروابط الحالية ولكن أيضًا توفير روابط جديدة وقد يكون مصدرًا جيدًا لتحقيق ذلك.

أنا أستخدم أيضًا ReactiveCocoa و Rex في وظيفتي الحالية ، لذا فأنا متاح أيضًا ومهتم بالمساعدة في أي شيء أستطيعه.

لمعلوماتك ، لقد أضفت عرض Rex التجريبي في ملعبي الشخصي https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
كود رائع حقًا حتى الآن ، وأعتقد أن مجرد الترحيل إلى org يكفي للخطوة الأولى: البريق:

إنها فكرة رائعة لجعل Rex جزءًا رسميًا من ReactiveCocoa. نظرًا لأن Swift يجعل من السهل حقًا تقسيم الكود إلى وحدات متعددة مع الحفاظ على الوظيفة الأساسية في الوحدة الرئيسية وإدخال وحدة ثانية للإضافات الخاصة بواجهة المستخدم أمر منطقي بالتأكيد.

أقترح التغييرات التالية:

• إعادة تسمية Rex لتوضيح أنه امتداد لـ ReactiveCocoa وأنه (في الغالب) يتعلق بواجهة المستخدم (كما ذكرtonyarnold)
• تغيير البادئة rex_xxx إلى rac_xxx لجعل التسمية متسقة

lukaskubanek أوافق على النقطة الأولى ، لكن لدي آراء مختلطة حول:

تغيير البادئة rex_xxx إلى rac_xxx لجعل التسمية متسقة

على الرغم من أنه سيظل التسمية متسقة ، إلا أن وجودها بأسماء مختلفة ، IMHO ، له العديد من المزايا:

1. قد أقوم بتضمين كل من libs في بداية المشروع بافتراض أنني سأحتاج إلى كليهما. في النهاية ، مع تطور المشروع ، قد أتوقف عن استخدام أي من مشغلي Rex. سيساعدني البحث السريع في المشروع عن rex_ في تأكيد ذلك وإزالته من التبعية.
2. إذا كان هناك سلوك غريب في عامل واحد ، فأنا أعرف على الفور المشروع الذي يجب فتح المشكلة فيه (كونه سؤالاً أو خطأً).
3. إنه يساعد المبتدئين في فهم أي منهم هم المشغلون الأساسيون ، ومن أين يتم بناء جميع الآخرين.

لقد ناقشنا نقل كود Swift الأساسي ، ورمز Obj-C ، وجسر Swift <-> Obj-C إلى مستودعات منفصلة (# 2807) ، وترك هذا الريبو لربط Cocoa ... لذلك أعتقد أنه يجب علينا نقل Rex رمز في هذا المستودع كـ RAC 5.

neilpaNachoSoto ما رأيك ؟

هل ستتم إزالة تبعية ارتباطات Rex و Swift على واجهات برمجة تطبيقات ReactiveCocoa ObjC أثناء الفصل ، أي إعادة تنفيذها في Swift؟ خلاف ذلك ، لن تكون IMO المنقسمة فعالة حقًا في أشياء أخرى غير الصيانة ، نظرًا لأن مستخدمي Swift لا يزالون بحاجة إلى إنشاء مكتبة ObjC بأكملها لبضع طرق مترابطة.

هل ستتم إزالة تبعية ارتباطات Rex و Swift على واجهات برمجة تطبيقات ReactiveCocoa ObjC أثناء الفصل ، أي إعادة تنفيذها في Swift؟

نعم! من المؤكد أنها ستشمل بعض Objective-C ، ولكنها لن تتضمن ReactiveObjC.

لذلك أعتقد أننا يجب أن ننقل كود Rex إلى هذا المستودع مثل RAC 5.

متفق عليه ، لكننا سنحتاج إلى توخي الحذر بشأن تاريخ إعادة الشراء. يجب أن نضع خطة لإدارة النقل / إعادة القاعدة / الانقسام التي تحافظ على سجل إعادة الشراء السليم.

هناك أيضًا تداعيات للمشكلات المفتوحة التي ليس لدينا الخيار المحتمل subtree split .

أفترض أن هذا تم الآن ، بفضل # 3210!