स्केलेबल टाइपस्क्रिप्ट अनुप्रयोगों का निर्माण। भाग 2 - इवेंट या क्यों यह आपकी खुद की बाइक को फिर से स्थापित करने के लायक है

लेख के पहले भाग में, मैंने Essential.js और मानक टाइपस्क्रिप्ट भाषा टूल का उपयोग करके अतुल्यकालिक लोडिंग मॉड्यूल के बारे में बात की। लापरवाही से, मैंने समय से पहले अमूर्त घटनाओं के साथ काम के आयोजन के विषय को छुआ, जो मुझे टिप्पणियों में बहुत जल्दी याद आया। विशेष रूप से, यह सवाल पूछा गया था कि अगर लंबे समय से एक सिद्ध और उत्कृष्ट रूप से काम करने वाली बैकबोन.ईवेंट और अन्य एनालॉग्स हैं तो अपनी खुद की बाइक के साथ क्यों आएं।

यदि आप इस प्रश्न के उत्तर में रुचि रखते हैं, तो टाइपस्क्रिप्ट पर एक वैकल्पिक कार्यान्वयन और कोड को पढ़ने से डरते नहीं हैं, तो मैं एक बिल्ली के लिए पूछता हूं।

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

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

1. शास्त्रीय OOP में अशुद्धियों का एक एनालॉग कई विरासत है। मैं "पवित्र युद्ध" में प्रवेश नहीं करना चाहता, लेकिन मेरी राय में कई विरासत हमेशा खराब होती हैं। विशेष रूप से डायनामिक टाइपिंग के संदर्भ में, कम से कम स्पष्ट या निहित कार्यान्वयन के माध्यम से वस्तुओं के व्यवहार को नियंत्रित करने की क्षमता के बिना इंटरफेस एक ला #। स्वाभाविक रूप से, आप इस बारे में जेएस में भी सपना नहीं देख सकते हैं, इसलिए इस तरह के कोड को डिबग करना, बनाए रखना और फिर से तैयार करना पूरी तरह से बुरा सपना है।
2. यदि हम उच्च मामलों से विचलित होते हैं, तो टीएस बस भाषा स्तर पर इसका समर्थन नहीं करता है। बैकबोन का विस्तार टीएस में विरासत का एक पूर्ण एनालॉग है और यह मॉडल और व्यू के लिए काम करता है, लेकिन घटनाओं के लिए बिल्कुल उपयुक्त नहीं है। नहीं, निश्चित रूप से हम Backbone.Event या इसके एनालॉग के आधार पर फ्रेमवर्क के आधार पर आवेदन में सभी वर्गों को प्राप्त कर सकते हैं और परिणाम प्राप्त कर सकते हैं, लेकिन यह 3 समस्या को हल नहीं करता है:
3. बैकबोन या किसी अन्य जेएस फ्रेमवर्क की घटनाओं को टाइप नहीं किया जाता है। अलविदा स्थिर विश्लेषण और टीएस के सभी लाभ।

सामान्य रूप से कौन सी घटनाएं होती हैं और सामान्य रूप से उनसे क्या आवश्यक है

यदि आप विडल्ड में नहीं जाते हैं, तो एक घटना बाहरी या उत्पन्न से आवेदन द्वारा प्राप्त कुछ संकेत है, जिसके प्राप्त होने पर आवेदन कुछ भी कर सकता है या नहीं कर सकता है। व्यक्तिगत रूप से, मुझे नहीं पता कि घटनाओं के बारे में और क्या कहा जा सकता है यदि आप मुझे 2 बजे उठाते हैं, तो मेरे चेहरे पर एक टॉर्च डालें और पूछताछ शुरू करें)

लेकिन एक निश्चित संदर्भ प्रकट होने पर सब कुछ बदल जाता है। हमारे मामले में, संदर्भ जावास्क्रिप्ट है, जो टीएस के रूप में किसी भी ऐड-ऑन के बिना पहले से ही 100% ओओपी भाषा है। विशेष रूप से, JS में सभी इकाइयाँ ऑब्जेक्ट हैं। ब्राउज़र द्वारा बनाई गई एक ही वस्तु डोनवेंट है। यही है, अगर हम सादृश्य जारी रखते हैं, तो कोई भी घटना एक वस्तु है।

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

लेकिन एक पल रुकिए। हमारा लक्ष्य क्या है? स्थिर कोड विश्लेषण प्राप्त करें। इसका मतलब है कि घटना एक वस्तु होनी चाहिए और एक प्रकार - श्रेणी होनी चाहिए। यह पहली आवश्यकता है जो एक परिणाम प्राप्त करने के लिए आवश्यक है। घटनाओं को कक्षाओं द्वारा वर्णित किया जाना चाहिए ताकि उन्हें टाइप किया जा सके।

इसका तात्पर्य दूसरी आवश्यकता से है - घटनाओं को संसाधित किया जाना चाहिए और उसी तरह काम करना चाहिए, अर्थात्। बेस क्लास से विरासत में मिला। यदि घटनाओं को विरासत में मिला है, तो बिना SOLID के विडाल आदि में भी, यह स्पष्ट है कि उनसे विरासत में प्राप्त करना पूरी तरह से बुरा विचार है।

तीसरी आवश्यकता न्यूनतम आवश्यक कार्यक्षमता है। आप किसी ईवेंट की सदस्यता ले सकते हैं, उसमें से सदस्यता समाप्त कर सकते हैं और उसे कॉल भी कर सकते हैं। बाकी सब महत्वपूर्ण नहीं है। स्वाभाविक रूप से, एक घटना में कोई एक या कई हैंडलर हो सकते हैं।

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

पांचवां, मैं चाहता हूं कि घटनाओं को विरासत के पदानुक्रम की परवाह किए बिना किसी भी वस्तु का हिस्सा होना चाहिए।

विचारों का एक समूह एकत्र करने और केएमएफडीएम चालू करने के बाद, मैं अपने द्वारा बनाई गई समस्याओं को हल करने के लिए आगे बढ़ता हूं।

कोडप्लेक्स पर स्रोत, https://tsasyncmodulesexampleapp.codeplex.com

पहले विचार

और इसलिए, कोई भी वस्तु, घटना एक वर्ग है, आदि। इसका मतलब 2 चीजें हैं: सबसे पहले, हमारे पास आधार वर्ग घटना है:

export class Event { //   Add(callback: any): void { /*    */ } Remove(callback: any): void { /*    */ } Trigger(): void { /*    */ } } 

दूसरे, हम इसे इस तरह से उपयोग करेंगे, सावधानी से सी # की दिशा में चुपके से देख रहे हैं और उनके उदाहरण से प्रेरित हैं:

 /// <reference path="Events.ts" /> import Events = require('Framework/Events'); export class MessagesRepo { public MessagesLoaded: Events.Event = new Events.Event(); } class SomeEventSubscriber { // .    private MessagesRepo = new MessagesRepo(); public Foo() { this.MessagesRepo.MessagesLoaded.Add(function () { alert('MessagesLoaded'); }); } } 

यानी एक घटना एक वर्ग का सिर्फ एक सार्वजनिक सदस्य है। न ज्यादा और न कम। यह हमें क्या देता है:

• संकलन समय पर ज्ञात कार्यक्रम
• घटनाओं की घोषणा किसी भी वर्ग में की जा सकती है।
• हमारे पास न्यूनतम आवश्यक कार्यक्षमता है, यह एक स्थान पर केंद्रित है और आसानी से संशोधित है।
• सभी घटनाओं को एक वर्ग या उसके उत्तराधिकारियों द्वारा कार्यान्वित किया जाता है, अर्थात्। उदाहरण के लिए, ईवेंट से विरासत में मिली सिक्योरइवेंट का वंशज बनाकर, कॉलबैक बनाकर और केवल कुछ शर्तों के तहत हम उनके काम के तर्क को आसानी से बदल सकते हैं।
• एक संदर्भ के साथ कोई विशिष्ट जेएस बवासीर नहीं है जो अब सख्ती से ऑब्जेक्ट इंस्टेंसेस, ईवेंट नामों में टाइपो, आदि पर निर्भर करता है।

हमारे पास अभी भी नहीं है:

1. सख्त टाइपिंग
2. संदर्भ की कमी के कारण, एक अनाम फ़ंक्शन द्वारा निर्दिष्ट कॉलबैक घटना से सदस्यता समाप्त करना असंभव है, अर्थात हमें कहीं भी किसी भी कॉलबैक को बचाना चाहिए, जो असुविधाजनक है।
3. गैर-टाइप किए गए ईवेंट पैरामीटर

मजबूत टाइपिंग

हम पहली समस्या से निपटेंगे। हम टाइपस्क्रिप्ट 0.9 के नवाचार का उपयोग करते हैं - जेनरिक:

 export class Event<Callback extends Function> { //    Add(callback: Callback): void { /*    */ } Remove(callback: Callback): void { /*    */ } Trigger(): void { /*    */ } } 

और आवेदन देखें:

 /// <reference path="Events.ts" /> import Events = require('Framework/Events'); export class MessagesRepo { public MessagesLoaded: Events.Event<{ (messages: string[]): void }> = new Events.Event<{ (messages: string[]): void }>(); } class SomeEventSubscriber { // .    private MessagesRepo = new MessagesRepo(); public Foo() { this.MessagesRepo.MessagesLoaded.Add(function (messages: string[]) { alert('MessagesLoaded'); }); } } 

इस मामले में, निम्नलिखित कोड:

 public Foo() { this.MessagesRepo.MessagesLoaded.Add(function (message: string) { alert('MessagesLoaded'); }); } 

यह एक त्रुटि देगा:

Supplied parameters do not match any signature of call target:
Call signatures of types '(message: string) => void' and '(messages: string[]) => void' are incompatible:
Type 'String' is missing property 'join' from type 'string[]'

मापदंडों के बिना एक कॉलबैक (ठीक है, हमें उनकी आवश्यकता नहीं है) शांति से संकलित करता है:

 public Foo() { this.MessagesRepo.MessagesLoaded.Add(function () { alert('MessagesLoaded'); }); } 

Callback extends Function होता है, उचित संकलन के लिए Callback extends Function निर्माण आवश्यक है टीएस को पता होना चाहिए कि Callback कहा जा सकता है।

अनाम कॉलबैक और सदस्यता स्थिति रिटर्न

जैसा कि मैंने ऊपर लिखा है, इस कार्यान्वयन के साथ, हम गुमनाम कॉलबैक को अनसब्सक्राइब नहीं कर सकते हैं, जिससे जेएस को अपने अनाम कार्यों और शानदार वेरिएबल्स की घोषणा के साथ संक्षिप्त रूप से पूरी तरह से अप्राप्य हो जाता है। उदाहरण के लिए:

 private FooMessagesLoadedCallback = function () { alert('MessagesLoaded'); } public Foo() { this.MessagesRepo.MessagesLoaded.Add(this.FooMessagesLoadedCallback); } 

मेरी राय में, यह एक पूर्ण मस्तिष्क उद्यम है और जेएस / टीएस की सभी कार्यात्मक विशेषताओं की हत्या है।

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

मैं निम्नलिखित तरीके से दूसरी समस्या को हल करने का प्रस्ताव करता हूं:

 export class Event<Callback extends Function> { public Add(callback: Callback): ITypedSubscription<Callback, Event<Callback>> { var that = this; var res: ITypedSubscription<Callback, Event<Callback>> = { Callback: callback, Event: that, Unsubscribe: function () { that.Remove(callback); } } /*    */ return res; } public Remove(callback: Callback): void { /*    */ } public Trigger(): void { /*    */ } } /**     .  .     . */ export interface ISubscription { Unsubscribe: { (): void }; } /**  .      callback */ export interface ITypedSubscription<Callback, Event> extends ISubscription { Callback: Callback; Event: Event; } 

यही है, हम बस ईवेंट विधि, कॉलबैक, और आवरण विधि में निकालें विधि के लिए आवरण को वापस करते हैं। उसके बाद, यह सब्सक्राइबर के लिए प्राथमिक "फाइनल" लागू करने के लिए बना रहता है:

 /** ,    IntelliSense ;) */ class SomeEventSubscriber { private MessagesRepo = new MessagesRepo(); /**        */ private Subscriptions: Events.ISubscription[] = []; public Foo() { //      this.Subscriptions.push(this.MessagesRepo.MessagesLoaded.Add(function () { alert('MessagesLoaded'); })); //   this.Subscriptions.push(this.MessagesRepo.ErrorHappened.Add(function (error: any) { alert(error); })); } /**             */ public Destroy() { for (var i = 0; i < this.Subscriptions.length; i++) { this.Subscriptions[i].Unsubscribe(); } this.Subscriptions = []; } } 

टाइपिंग इवेंट पैरामीटर

सब कुछ बहुत सरल है। फिर से हम सामान्यीकरण का उपयोग करते हैं:

 export class Event<Callback extends Function, Options> { public Add(callback: Callback): ITypedSubscription<Callback, Event<Callback, Options>> { var that = this; var res: ITypedSubscription<Callback, Event<Callback, Options>> = { Callback: callback, Event: that, Unsubscribe: function () { that.Remove(callback); } } /*    */ return res; } public Remove(callback: Callback): void { /*    */ } public Trigger(options: Options): void { /*    */ } } 

प्रकाशक वर्ग अब इस तरह दिखेगा:

 export interface ErrorHappenedOptions { Error: any; } export class MessagesRepo { public MessagesLoaded: Events.Event< { (messages: string[]): void } //Callback , string[]> //Options = new Events.Event<{ (messages: string[]): void }, string[]>(); public ErrorHappened: Events.Event< { (error: ErrorHappenedOptions): void }, //Callback ErrorHappenedOptions> //Options = new Events.Event<{ (error: ErrorHappenedOptions): void }, ErrorHappenedOptions>(); } 

और इवेंट कॉल इस तरह:

 var subscriber: Messages.SomeEventSubscriber = new Messages.SomeEventSubscriber(); subscriber.MessagesRepo.MessagesLoaded.Trigger(['Test message 1']); subscriber.MessagesRepo.ErrorHappened.Trigger({ Error: 'Test error 1' }); 

इस पर घटनाओं के लिए मेरी विशलिस्ट समाप्त हो जाती है। पूर्ण स्रोत कोड और एक वैध उदाहरण के लिए, मैं कोडप्लेक्स के लिए पूछता हूं ।

पहले भाग के सकारात्मक मूल्यांकन के लिए आप सभी का धन्यवाद।

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

टिप्पणियों के अनुसार बग पर काम करें:
भाग 2.5: स्केलेबल टाइपस्क्रिप्ट अनुप्रयोगों का निर्माण - भाग 2.5। बग और प्रतिनिधियों पर काम करते हैं