Reactivecocoa: `एक्शन` के लिए बाइंडिंग को नियंत्रित करें।

को निर्मित 4 अक्तू॰ 2016 · 22टिप्पणियाँ · स्रोत: ReactiveCocoa/ReactiveCocoa

दो एपीआई हैं जो कमांड पैटर्न का उपयोग करते हैं। जैसा कि @sharplet ने कहा, इन्हें ReactiveObjC से लाया गया हो सकता है, उदाहरण के लिए button.rac_command ।

extension Reactive where Host: UIButton {
    public var pressed: MutableProperty<CocoaAction> { ... }
}

extension Reactive where Host: UIBarButtonItem {
    public var pressed: MutableProperty<CocoaAction> { ... }
}

एक मजबूत संदर्भ के साथ Action स्वामित्व वाले दृश्य को देखना गलत लगता है। Action (अप्रत्यक्ष रूप से CocoaAction माध्यम से) का स्वामित्व इसकी मूल परत पर छोड़ दिया जाना चाहिए (चाहे वह वीसी या वीएम हो)।

इसलिए, @liscio और @sharplet के साथ लंबी चर्चा के बाद, विशेष रूप से Action के लिए UIControl और NSControl s के साथ जुड़ने के लिए एक नया इंटरफ़ेस तैयार करने का प्रस्ताव है। अवधारणा इस प्रकार है:

extension Reactive where Base: UIControl {
    /// Create a trigger signal for a specific set of control events.
    public func trigger(for controlEvents: UIControlEvents) -> Signal<(), NoError>

    /// The action is weakly referenced internally.
    public func setAction<Input, Output, Error>(_ action: Action<Input, Output, Error>, for controlEvents: UIControlEvents, inputTransform: (Self, UIControlEvents) -> Input)

    public func removeAction()

    /// ... some convenience overloads of `setAction(_:for:inputTransform:)`.
}

इस एपीआई के साथ, हम यूआईसींट्रोल और एनएससींट्रोल उपवर्गों से सभी Action बाध्यकारी लक्ष्यों को हटा देंगे, क्योंकि एपीआई को उन सभी को कवर करना चाहिए था।

अधिक अर्थ में, हम @IBAction और @IBOutlet पीछे लक्ष्य-क्रिया पैटर्न की नकल करेंगे।

इंटरफ़ेस बिल्डर में, हम UIButton के _Sent Action_ को UIViewController के _Received Action_ ( @IBAction विधि) से बाँध सकते हैं, और UIButton कमजोर संदर्भित लक्ष्य को एक संदेश भेजता है।

हमारे मामले में, हम नियंत्रणों पर घटना संकेतों के संग्रह का पर्दाफाश करेंगे। बाध्यकारी लक्ष्य के रूप में Action s के साथ, Action भूमिका @IBAction समान हो सकती है। उदाहरण के लिए:

// Received Action <~ Sent Action
commitAction <~ confirmButton.touchUpInside

// The reverse `isEnabled` binding is now explicit & optional.
confirmButton.isEnabled <~ commitAction.isEnabled

// OR

confirmButton.setAction(commitAction, for: .touchUpInside)

जो के समकक्ष हैं

confirmButton.rac_pressed.value = CocoaAction(commitAction)

लेकिन हमारे कमजोर-से-कमजोर बाध्यकारी शब्दार्थ के माध्यम से एक अलग स्वामित्व के साथ।

enhancement

स्रोत

andersio

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

फिर छुपा लेंगे। इसे सरल रखें।

andersio 7 अक्तू॰ 2016

👍2

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

यह न भूलें कि हमें समान कार्यक्षमता के लिए भी इसकी आवश्यकता होगी:

confirmButton.rac.isEnabled <~ commitAction.isEnabled

sharplet 4 अक्तू॰ 2016

👍1

हम्म, मैंने इसे अनदेखा कर दिया। ~~ऐसा लगता है कि हमें Action साथ पूरी तरह से जाना चाहिए।~~

andersio 4 अक्तू॰ 2016

@andersio मुझे यकीन नहीं है कि इसका क्या मतलब है, और इसके परिणामस्वरूप यह मुद्दा क्यों बंद हो गया।

@sharplet क्या लाता है, इसे isEnabled इनलेट में अलग करना ठीक है।

उस तथ्य को एक सुविधा पद्धति/पैटर्न में छिपाना, मेरी राय में, हमें ज्यादा नहीं खरीद रहा है।

liscio 4 अक्तू॰ 2016

https://github.com/ReactiveCocoa/ReactiveCocoa/pull/3210/commits/f983a746f915a9a517e9e076c19581724075c562 में लागू किया गया

andersio 4 अक्तू॰ 2016

एक मजबूत संदर्भ के साथ कार्रवाई के मालिक होने के विचार को गलत लगता है। कार्रवाई का स्वामित्व (अप्रत्यक्ष रूप से CocoaAction के माध्यम से) इसकी मूल परत पर छोड़ दिया जाना चाहिए (चाहे वह VC या VM हो)।

मुझे नहीं लगता कि मैं सहमत हूं। यह आपको गलत क्यों लगता है?

mdiep 5 अक्तू॰ 2016

कमजोर संदर्भ प्रस्तावित एपीआई का एक छोटा सा हिस्सा है, जो UIControl विधियों के एक सेट को धक्का देता है जो कमांड पैटर्न ( Action माध्यम से) का उपयोग करके सभी नियंत्रणों को कवर करता है।

रेक्स में, यह विशिष्ट कार्यान्वयन के साथ UIButton के लिए विशिष्ट था।

AFAIK, एक `Action` आमतौर पर एक कमांड का प्रतिनिधित्व करता है, एक दृश्य मॉडल के स्वामित्व में है, और इसकी स्थिति से/पर आंतरिक और बाहरी दोनों निर्भरताएं होने की संभावना है। कोको लक्ष्य-क्रिया पैटर्न की तरह, मुझे नहीं लगता कि यह एक स्पष्ट संदर्भ होने पर एक मजबूत संदर्भ क्यों होना चाहिए।
एक मजबूत संदर्भ का उपयोग करने वाला रेक्स एपीआई संभावित रूप से `CocoaAction` व्यवहार का एक शिल्प है, जिसे बनाए रखने की आवश्यकता है ताकि मूल्यों को लपेटे गए `Action` प्रचारित किया जा सके।
इसके बजाय यहां प्रस्तावित एपीआई सीधे `Action` लेता है।

andersio 5 अक्तू॰ 2016

रेक्स 0.12:

extension UIButton {
    public var rex_pressed: MutableProperty<CocoaAction> { get }

    // This one would become `BindingTarget`. Irrelevant to this issue.
    public var rex_title: MutableProperty<String> { get }
}

प्रस्तावित (सभी UIControl s पर काम करता है):

extension Reactive where Base: UIControl {
    /// The action is weakly referenced internally.
    public func setAction<Input, Output, Error>(
        _ action: Action<Input, Output, Error>,
        for controlEvents: UIControlEvents,
        inputTransform: (Self, UIControlEvents) -> Input
    )

    public func removeAction()

    /// ... some convenience overloads of `setAction(_:for:inputTransform:)`.
}

सामान्यतया, हमारे पास UI राज्यों के तीन वर्ग हैं + एक विशेष रूप से `Action` साथ कमांड पैटर्न के लिए:
परिवर्तनशील कुंजियाँ जिनका कोई साधन या मान नहीं है।
जैसे `UIControl.isEnabled` , `UILabel.text` , `UIView.isHidden` ।
`BindingTarget` s के रूप में मॉडल।
नियंत्रण घटनाओं, और विधि कॉल की सूचनाएं।
जैसे `UIControl.trigger(for: .valueChanged)` , `UITableViewCell.trigger(for: #selector(prepareForReuse))`
`Signal` s के रूप में मॉडल।
परिवर्तनीय कुंजियाँ + संबंधित नियंत्रण घटना जो उपयोगकर्ता के इंटरैक्शन पर पोस्ट करती है।
उदाहरण के लिए `UITextField.text` , `NSTextField.text` , `UISwitch.isOn`
#3229
[ _ `Action` को एक नियंत्रण के साथ जोड़ना।
(यह केवल [1] और [2] के शीर्ष पर निर्मित एक सुविधा पैटर्न है।)
उदाहरण के लिए `UIButton.rac_command`
_इस मुद्दे। _

andersio 5 अक्तू॰ 2016

@andersio मुझे लगता है कि दुर्भाग्य से removeAction() भी क्या नियंत्रण घटनाओं आप के लिए कार्रवाई निकाल रहे हैं 1.0 के लिए सिर्फ _or_ मैं इसका नाम बदलना चाहते हैं निर्दिष्ट करने के लिए होगा removeAllActions() और के लिए एक नोट जोड़ने setAction() यह इंगित करने के लिए कि नियंत्रण वर्तमान में इस "आसान एपीआई" का उपयोग करके केवल एक ही क्रिया को संभालता है, क्योंकि वैसे भी 99.9% लोग इसका उपयोग करेंगे।

liscio 5 अक्तू॰ 2016

यह विचारणीय है। आईएमओ कई कार्रवाइयां समझ में नहीं आती हैं, क्योंकि इस मामले में एकाधिक क्रियाएं isEnabled समवर्ती (= थोड़े अनिश्चित) में हेरफेर कर सकती हैं।

andersio 5 अक्तू॰ 2016

क्यों न जोड़ें (स्विफ्ट) गुण जो सीधे दी गई कार्रवाई को सेट करते हैं?

extension Reactive where Base: UIButton {
    var pressed: CocoaAction {
        get { … }
        set { … }
    } 
}

या शायद वह आपके some convenience overloads अनुभाग में शामिल था?

मुझे लगता है कि अगर हम एक सामान्य एपीआई जोड़ना चाहते हैं तो यह ठीक है, लेकिन मुझे लगता है कि सुविधा एपीआई अधिक महत्वपूर्ण हैं। यही वह एपीआई है जिसे मैं दुनिया को दिखाऊंगा। मुझे लगता है कि ऐसा कुछ बहुत ही आकर्षक है:

button.reactive.pressed = CocoaAction(viewModel.action)

जब तक हम setAction(…) साथ जा रहे हैं, संभवतः nil कार्रवाई सेट करके हटाया जाना चाहिए। एक अलग एपीआई की जरूरत नहीं है।

mdiep 6 अक्तू॰ 2016

यह निस्संदेह बेहतर दिखता है, हाँ। इन्हें जरूर रखना चाहिए। मैं अभी भी CocoaAction को Action लिए कमजोर संदर्भ बनाने का प्रस्ताव करता हूं।

andersio 6 अक्तू॰ 2016

setAction अपडेट किया गया ( 790b3e8 ), और pressed वापस आ गया है ( 790b3e8 )।

extension Reactive where Base: UIButton {
    public var pressed: CocoaAction<Base> { get nonmutating set }
}

extension Reactive where Base: UIControl {
    public var action: CocoaAction<Base>? { get }
    public var controlEventsForAction: UIControlEvents? { get }

    /// `CocoaAction` is retained by `self`, but `CocoaAction` weakly references `Action`.
    public func setAction(
        _ action: CocoaAction<Base>?,
        for controlEvents: UIControlEvents
    )
}

andersio 6 अक्तू॰ 2016

मुझे लगता है कि एपीआई को कई कार्यों का समर्थन करने की आवश्यकता होगी। तो यह मान्य होना चाहिए:

button.reactive.setAction(action1, for: .touchUpInside)
button.reactive.setAction(action2, for: .touchUpOutside)
// button now has 2 actions set for 2 different events

CocoaAction कमजोर रूप से Action संदर्भ क्यों देता है?

mdiep 7 अक्तू॰ 2016

@mdiep

// button now has 2 actions set for 2 different events

इसका मतलब यह होगा कि button की सक्षम स्थिति action1.isEnabled और action2.isEnabled दोनों के लिए बाध्य है। मुझे यकीन नहीं है कि हम यही चाहते हैं। सक्षम राज्य कैसे निर्धारित किया जाना चाहिए? एक AND सभी Action s' सक्षम करने वाली स्थिति का?

कोकोएक्शन कमजोर रूप से कार्रवाई का संदर्भ क्यों देता है?

इसे वापस कर दिया। मैं मानता हूँ कि यह अभी के लिए (और रेक्स के इतिहास के दौरान) परेशानी का कारण नहीं बनता है।

andersio 7 अक्तू॰ 2016

इसका मतलब यह होगा कि बटन की सक्षम स्थिति दोनों action1.isEnabled और action2.isEnabled के लिए बाध्य है। मुझे यकीन नहीं है कि हम यही चाहते हैं। सक्षम राज्य कैसे निर्धारित किया जाना चाहिए? एक और सभी कार्रवाइयों को सक्षम करने वाला राज्य?

और मुझे सही नहीं लगता।

यहां हमारे विकल्प हैं:

पूरी तरह से सक्षम करना छोड़ दें
और सभी कार्रवाइयां 'सक्षम स्थिति
या सभी कार्रवाइयों की सक्षम स्थिति
अगर ठीक 1 क्रिया है तो सक्षम करें
.pressed , आदि में सक्षम करें और सीधे setAction(:for:)

(5) मेरे लिए सबसे अच्छा समाधान लगता है। सामान्य मामला आसान और सुविधाजनक है। यदि आप कुछ अधिक जटिल करना चाहते हैं, तब भी आप कर सकते हैं।

mdiep 7 अक्तू॰ 2016

(5) का अर्थ है setAction को कई actionN <~ reactive.trigger(for: .specificEvent) करने से कोई फर्क नहीं पड़ेगा। इसके अलावा, यदि नियंत्रण में एकाधिक सुविधा कमांड स्लॉट हों तो क्या होगा?

andersio 7 अक्तू॰ 2016

इसमें अभी भी अलग है:

रद्द करना अलग है
यह प्रति घटना केवल एक क्रिया की अनुमति देता है
यह CocoaAction . के इनपुट के रूप में नियंत्रण पास करता है

अन्यथा वे मोटे तौर पर वही हैं, हाँ। लेकिन मुझे लगता है कि यह ठीक है।

mdiep 7 अक्तू॰ 2016

यदि योजना एक से अधिक कार्यों का समर्थन करने की है, तो हमें संभवतः इसका नाम बदलकर addAction कर देना चाहिए।

sharplet 7 अक्तू॰ 2016

मान लीजिए कि अगर हम propagateEnablingState तर्क को setAction जोड़ते हैं, तो हमें अभी भी यह तय करना होगा कि isEnabled के वेक्टर को कैसे संभालना है। (कॉन्फ़िगर करने योग्य? जैसे और/या/अपरिभाषित?)

andersio 7 अक्तू॰ 2016

मुझे यकीन नहीं है कि यह "सुविधा संपत्ति" में 1 कार्रवाई का समर्थन करने लायक है, जिस पर यहां चर्चा की जा रही है, क्योंकि हमने उन लोगों के लिए वैकल्पिक उपयोग (व्यक्तिगत रूप से trigger(for:) साथ कार्रवाइयां ट्रिगर करना) छोड़ दिया है जिन्हें एक से अधिक की आवश्यकता है।

उपयोग में आसान विकल्प (यह हमारे अन्य सिग्नल/बाइंडिंग लक्ष्य सामग्री के उपयोग से मेल खाने के लिए भी होता है) को देखते हुए मुझे इस तरह से एक बटन में एक से अधिक क्रियाओं को जोड़ने का एक अच्छा कारण नहीं दिख रहा है।

मूल रूप से, यदि आप एक "सरल एपीआई" चाहते हैं, तो आप यहां की तरह action संपत्ति का उपयोग करें। इसकी सक्षम स्थिति बटन में दिखाई देती है।

यदि आप >1 क्रिया के लिए एक बटन संलग्न करना चाहते हैं, तो आप उनके व्यक्तिगत trigger s का उपयोग करते हैं, और फिर map को isEnabled BindingTarget में जोड़ने के लिए अपने स्वयं के map को हुक अप करते हैं। BindingTarget । क्या यह उचित लगता है?

liscio 7 अक्तू॰ 2016

👍1

मूल रूप से, यदि आप "सरल एपीआई" चाहते हैं, तो आप यहां की तरह एक्शन प्रॉपर्टी का उपयोग करते हैं। इसकी सक्षम स्थिति बटन में दिखाई देती है।
यदि आप >1 क्रिया के लिए एक बटन संलग्न करना चाहते हैं, तो आप उनके अलग-अलग ट्रिगर का उपयोग करते हैं, और फिर isEnabled BindingTarget में हुक करने के लिए अपने स्वयं के मानचित्र को हुक अप करते हैं। क्या यह उचित लगता है?

यह मुझे उचित लगता है।

तो क्या हमें setAction(:for:) ?

mdiep 7 अक्तू॰ 2016

फिर छुपा लेंगे। इसे सरल रखें।

andersio 7 अक्तू॰ 2016

👍2

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

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

Reactivecocoa: `एक्शन` के लिए बाइंडिंग को नियंत्रित करें।

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

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

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