हम किस तरह QIWI में MVVM के भीतर View और ViewModel के बीच बातचीत की एक आम शैली में आए

प्रारंभ में, पूरी परियोजना ऑब्जेक्टिव-सी में लिखी गई थी और इसका उपयोग रिएक्टिवकोआ संस्करण 2.0 में किया गया था

व्यू मॉडल के गुणों के बाइंडिंग के माध्यम से View और ViewModel के बीच बातचीत को अंजाम दिया गया था, और सभी ठीक हो जाएंगे, सिवाय इसके कि इस तरह के कोड को डिबग करना बहुत मुश्किल था। स्टैक ट्रेस में टाइपिंग और दलिया की कमी के कारण सभी :(

और अब यह स्विफ्ट का उपयोग करने का समय है। सबसे पहले, हमने बिल्कुल प्रतिक्रिया किए बिना प्रयास करने का फैसला किया। ViewModel पर स्पष्ट रूप से कहे गए तरीके देखें, और ViewModel ने एक प्रतिनिधि का उपयोग करके अपने परिवर्तनों की सूचना दी:

protocol ViewModelDelegate { func didUpdateTitle(newTitle: String) } class View: UIView, ViewModelDelegate { var viewModel: ViewModel func didUpdateTitle(newTitle: String) { //handle viewModel updates } } class ViewModel { weak var delegate: ViewModelDelegate? func handleTouch() { //respond to some user action } } 

यह अच्छा लग रहा है। लेकिन जैसे-जैसे ViewModel बढ़ता गया, हमने ViewModel द्वारा उत्पादित हर छींक को संसाधित करने के लिए प्रतिनिधि में तरीकों का एक गुच्छा प्राप्त करना शुरू किया:

 protocol ViewModelDelegate { func didUpdate(title: String) func didUpdate(subtitle: String) func didReceive(items: [SomeItem]) func didReceive(error: Error) func didChangeLoading(isLoafing: Bool) //...  } 

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

आउटपुट स्वयं सुझाव देता है: आपको सभी तरीकों को एक में मिलाने की जरूरत है और एन्यूमरेशन गुण कुछ इस तरह से हैं:

 enum ViewModelEvent { case updateTitle(String) case updateSubtitle(String) case items([SomeItem]) case error(Error) case loading(Bool) //...  } 

पहली नज़र में, सार नहीं बदलता है। लेकिन छह तरीकों के बजाय, हमें एक स्विच के साथ मिलता है:

 func handle(event: ViewModelEvent) { switch event { case .updateTitle(let newTitle): //... case .updateSubtitle(let newSubtitle): //... case .items(let newItems): //... case .error(let error): //... case .loading(let isLoading): //... } } 

समरूपता के लिए, आप ViewModel में एक और गणना और उसके हैंडलर बना सकते हैं:

 enum ViewEvent { case touchButton case swipeLeft } class ViewModel { func handle(event: ViewEvent) { switch event { case .touchButton: //... case .swipeLeft: //... } } } 

यह सब बहुत अधिक संक्षिप्त दिखता है, साथ ही यह व्यू और व्यूमॉडल के बीच बातचीत का एक एकल बिंदु देता है, जो कोड की पठनीयता को बहुत अच्छी तरह से प्रभावित करता है। यह जीत-जीत बताती है - और पुल अनुरोध की समीक्षा त्वरित हो जाती है, और नवागंतुक जल्दी परियोजना में आते हैं।

लेकिन रामबाण नहीं। समस्या तब उत्पन्न होती है जब एक दृश्य मॉडल अपनी घटनाओं को कई दृश्यों में रिपोर्ट करना चाहता है, उदाहरण के लिए, कंटेनरव्यू और कंटेंटव्यू (एक दूसरे में एम्बेडेड है)। समाधान, फिर से, अपने आप उठता है, हम प्रतिनिधि के बजाय एक नया वर्ग लिखते हैं:

 class Output<Event> { var handlers = [(Event) -> Void]() func send(_ event: Event) { for handler in handlers { handler(event) } } } 

handlers संपत्ति में, handlers कॉल को handle(event:) विधियों handle(event:) साथ बुकमार्क स्टोर करते हैं, और जब हम send(_ event:) विधि कहते हैं, तो हम इस इवेंट के साथ सभी हैंडलर को कॉल करते हैं। और फिर, समस्या हल हो गई लगती है, लेकिन हर बार जब आप View - ViewModel को बांधते हैं, तो आपको यह लिखना होगा:

 vm.output.handlers.append({ [weak view] event in DispatchQueue.main.async { view?.handle(event: event) } }) view.output.handlers.append({ [weak vm] event in vm?.handle(event: event) }) 

बहुत अच्छा नहीं है।
हम प्रोटोकॉल के साथ दृश्य और ViewModel को बंद करते हैं:

 protocol ViewModel { associatedtype ViewEvent associatedtype ViewModelEvent var output: Output<ViewModelEvent> { get } func handle(event: ViewEvent) func start() } protocol View: ViewModelContainer { associatedtype ViewModelEvent associatedtype ViewEvent var output: Output<ViewEvent> { get } func setupBindings() func handle(event: ViewModelEvent) } 

क्यों start() और setupBindings() तरीकों की जरूरत है - हम बाद में वर्णन करेंगे। हम प्रोटोकॉल के लिए एक्सटेंशन लिख रहे हैं:

 extension View where Self: NSObject { func bind<ViewModelType: ViewModel>(with vm: ViewModelType?) where ViewModelType.ViewModelEvent == ViewModelEvent, ViewModelType.ViewEvent == ViewEvent { guard let vm = vm else { return } vm.output.handlers.append({ [weak self] event in DispatchQueue.main.async { self?.handle(event: event) } }) output.handlers.append({ [weak vm] event in vm?.handle(event: event) }) setupBindings() vm.start() } } 

और हमें किसी भी View - ViewModel को जोड़ने के लिए एक तैयार विधि प्राप्त होती है, जिसमें से मैच होते हैं। start() विधि यह सुनिश्चित करती है कि जब इसे निष्पादित किया जाता है, तो दृश्य पहले से ही सभी घटनाओं को प्राप्त करेगा जो ViewModel से भेजे जाएंगे, और अगर आपको ViewModel को अपने स्वयं के setupBindings() फेंकने की आवश्यकता है, तो setupBindings() विधि की आवश्यकता होगी, इसलिए इस विधि को डिफ़ॉल्ट रूप से विस्तार से लागू किया जा सकता है ' ई।

यह पता चलता है कि View और ViewModel के बीच संबंध के लिए, उनके विशिष्ट कार्यान्वयन बिल्कुल महत्वपूर्ण नहीं हैं, मुख्य बात यह है कि View ViewModel घटनाओं को संभाल सकता है, और इसके विपरीत। और देखने के लिए स्टोर करने के लिए ViewModel का एक विशिष्ट लिंक नहीं है, लेकिन इसका सामान्यीकृत संस्करण है, आप एक अतिरिक्त TypeEureure आवरण लिख सकते हैं (क्योंकि associatedtype प्रकार के साथ प्रोटोकॉल प्रकार के गुणों का उपयोग करना असंभव है):

 class AnyViewModel<ViewModelEvent, ViewEvent>: ViewModel { var output: Output<ViewModelEvent> let startClosure: EmptyClosure let handleClosure: (ViewEvent) -> Void let vm: Any? private var isStarted = false init?<ViewModelType: ViewModel>(with vm: ViewModelType?) where ViewModelType.ViewModelEvent == ViewModelEvent, ViewModelType.ViewEvent == ViewEvent { guard let vm = vm else { return nil } self.output = vm.output self.vm = vm self.startClosure = { [weak vm] in vm?.start() } self.handleClosure = { [weak vm] in vm?.handle(event: $0) }//vm.handle } func start() { if !isStarted { isStarted = true startClosure() } } func handle(event: ViewEvent) { handleClosure(event) } } 

आगे और भी

हमने आगे जाने का फैसला किया, और स्पष्ट रूप से संपत्ति को दृश्य में संग्रहीत नहीं किया, लेकिन रनटाइम के माध्यम से इसे सेट करें, कुल में, View प्रोटोकॉल का विस्तार इस तरह से निकला:

 extension View where Self: NSObject { func bind<ViewModelType: ViewModel>(with vm: ViewModelType?) where ViewModelType.ViewModelEvent == ViewModelEvent, ViewModelType.ViewEvent == ViewEvent { guard let vm = AnyViewModel(with: vm) else { return } vm.output.handlers.append({ [weak self] event in if #available(iOS 10.0, *) { RunLoop.main.perform(inModes: [.default], block: { self?.handle(event: event) }) } else { DispatchQueue.main.async { self?.handle(event: event) } } }) output.handlers.append({ [weak vm] event in vm?.handle(event: event) }) p_viewModelSaving = vm setupBindings() vm.start() } private var p_viewModelSaving: Any? { get { return objc_getAssociatedObject(self, &ViewModelSavingHandle) } set { objc_setAssociatedObject(self, &ViewModelSavingHandle, newValue, .OBJC_ASSOCIATION_RETAIN_NONATOMIC) } } var viewModel: AnyViewModel<ViewModelEvent, ViewEvent>? { return p_viewModelSaving as? AnyViewModel<ViewModelEvent, ViewEvent> } } 

यह एक विवादास्पद क्षण है, लेकिन हमने तय किया कि हर बार इस संपत्ति की घोषणा न करना अधिक सुविधाजनक होगा।

टेम्पलेट्स

यह दृष्टिकोण Xcode टेम्प्लेट के साथ पूरी तरह से फिट बैठता है और आपको कुछ क्लिकों में बहुत जल्दी मॉड्यूल उत्पन्न करने की अनुमति देता है। उदाहरण के लिए टेम्पलेट देखें:

 final class ___VARIABLE_moduleName___ViewController: UIView, View { var output = Output<___VARIABLE_moduleName___ViewModel.ViewEvent>() override func viewDidLoad() { super.viewDidLoad() setupViews() } private func setupViews() { //Do layout and more } func handle(event: ___VARIABLE_moduleName___ViewModel.ViewModelEvent) { } } 

और ViewModel के लिए:

 final class ___VARIABLE_moduleName___ViewModel: ViewModel { var output = Output<ViewModelEvent>() func start() { } func handle(event: ViewEvent) { } } extension ___VARIABLE_moduleName___ViewModel { enum ViewEvent { } enum ViewModelEvent { } } 

और कोड में मॉड्यूल इनिशियलाइज़ेशन बनाने में केवल तीन लाइनें लगती हैं:

 let viewModel = SomeViewModel() let view = SomeView() view.bind(with: viewModel) 

निष्कर्ष

नतीजतन, हमें View और ViewModel के बीच संदेशों के आदान-प्रदान का एक लचीला तरीका मिला, जिसमें एक प्रविष्टि बिंदु है और यह Xcode कोड पीढ़ी पर आधारित है। इस दृष्टिकोण ने सुविधाओं के विकास को गति देना और पुल-रिव्यू की समीक्षा को गति देना संभव बना दिया, इसके अलावा इसने कोड की पठनीयता और सरलता को बढ़ाया और परीक्षणों के लेखन को सरल बनाया (इस तथ्य के कारण कि, दृश्य मॉडल से घटनाओं को प्राप्त करने के वांछित अनुक्रम को जानते हुए, यूनिट-टेस्ट लिखना आसान है, जिसके साथ यह क्रम है गारंटी दी जा सकती है)। यद्यपि यह दृष्टिकोण हमारे साथ हाल ही में उपयोग किया जाना शुरू हुआ है, हम आशा करते हैं कि यह पूरी तरह से अपने आप को औचित्य देगा और विकास को बहुत सरल करेगा।

पुनश्च

और आईओएस के लिए विकास के प्रेमियों के लिए एक छोटी सी घोषणा - पहले से ही इस गुरुवार, 25 जुलाई, हम एआरटी-स्पेस में एक आईओएस mitap पकड़ लेंगे, प्रवेश नि: शुल्क है, आओ।