Reactivecocoa: كيف يجب أن نتعامل مع بادئات "rac_" في Swift 3؟

يمكننا إسقاط البادئات لأن الأنواع تجعل الأسماء واضحة - على الأقل في معظم الحالات. أو يمكننا الاحتفاظ بها. أنا على الحياد.

إذا احتفظنا بها ، فيجب علينا استخدام rac_ هنا (بما في ذلك الرمز من Rex) والعثور على بادئة جديدة لـ ReactiveSwift.

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

على سبيل المثال

view.bindables.text <~ property

// `view.bindables` is of type `Bindings<UIView>`, which conforms to `BindingsProtocol`
// that requires an associated type `Owner`.
//
// `view.bindables.text` is provided by the extension to `BindingsProtocol` for all
//`Owner` inherited from `UIView`.

(أو فقط rac ؟ لكن كلاً من ReactiveSwift و ReactiveCocoa يمكن أن يفضحا نوعًا من الارتباطات ، على ما أفترض)

... أو قم بتسميته view.textProxy أو view.reactiveText أو أيًا كان ، إيه.

تحرير: لقد قمت بتجميع نموذج أولي سريع (https://github.com/RACCommunity/Rex/pull/143).

تحرير 2: تنظيف الفوضى قليلا. : ص

لا يلزم أن يكون ReactiveCocoa 5+ متوافقًا مع Rex. سوف يستوعب RAC Rex.

بالتأكيد ، لقد قصدت فقط تلك الارتباطات التي جلبها ريكس. آسف إذا كان يقرأ مثل الفوضى. 😸

outlets منافسًا أيضًا.

"رد الفعل" هو الأفضل مع لغة سريعة. "rac_" و "rex_" هي تسمية سيئة للغاية. سأختار "رد الفعل" أو "نشط" أو "إشارة" حتى نتمكن من عرض نصوص view.reactiveText أو view.activeText أو view.signalText

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

إنه جيد بالنسبة للطرق. لكننا ما زلنا بحاجة إلى البحث عن نهج للخصائص ، حيث لا يمكن زيادة تحميل الخصائص. 😕

استنادًا إلى وكيل bindable مثل view.bindables.something ، قد نقدم اختصارات مثل %view.something . 😕

أعتقد أنه من الآمن استخلاص استنتاج مفاده أنه لا يمكننا تجنب / توضيح تصادمات وقت التجميع بأي شكل من الأشكال ، على الأقل في Swift 3.0. إن الاقتراحات مثل استخدام عوامل التشغيل أو الخاصية السحرية تحد فقط من إمكانية الاصطدام بكيان واحد.

سأخاطر بحدوث تصادم مع عامل التشغيل مقابل اختزال أجمل رغم ...

أعتقد أننا عالقون مع بادئات الخصائص في الوقت الحالي.

أحد الأشياء التي قمنا بها مع SnapKit هو إنشاء هيكل يستضيف الامتدادات ، ويمكن تخزين RAC api مثل:

struct UIButtonRACDSL {
    var pressed: Signal<UIButton, NoError>
    init(button: UIButton) { }
}

extension UIButton {
    var rac: UIButtonRACDSL { return UIButtonRACDSL(button: self) }
}

يوفر السير في هذا المسار بعض المرونة ويقلل من نطاق تصادم الامتدادات.

نعم ، لقد طرحته من قبل باستخدام إصدار قائم على البروتوكول. يستبدل الشرطة السفلية بنقطة ، ويسمح بإدخال اختصار عامل التشغيل. استخدام IMO rac كاسم الخاصية سيكون جيدًا ، لأنه ليس اختصارًا شائعًا على أي حال.

https://github.com/RACCommunity/Rex/pull/143

خاصية rac ستبدو أكثر نظافة ... SOOO MUUCH !!! :عيون القلب:

أعتقد أننا يجب أن نسرق النهج الذي اتبعته RxSwift.

https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/Common/Reactive.swift
https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/iOS/UIControl٪2BRx.swift

لقد أضافوا بنية ، Reactive تكون عامة على النوع الذي يريدون تمديده. ثم أضافوا طرقًا على الامتدادات المقيدة إلى Reactive . من الواضح أنهم قاموا بتصميم هذا على غرار Swift's .lazy .

ربما لا يسرق.

https://github.com/RACCommunity/Rex/pull/143/commits/86f03c3b2d4759c87254a9ea3b28939f23f6be56
😜