परिचय

कोणीय वाक्यविन्यास (eventName)="onEventName($event)" का उपयोग करके टेम्पलेट में घटनाओं की सदस्यता के लिए एक सुविधाजनक घोषणात्मक तरीका प्रदान करता है। ChangeDetectionStrategy.OnPush परिवर्तन जाँच नीति के साथ, यह दृष्टिकोण स्वचालित रूप से केवल उपयोगकर्ता इनपुट के लिए परिवर्तन जाँच चक्र शुरू करता है जो हमें ChangeDetectionStrategy.OnPush है। दूसरे शब्दों में, यदि हम <input> तत्व पर (input) ईवेंट सुनते हैं, तो उपयोगकर्ता द्वारा इनपुट फ़ील्ड पर क्लिक करने पर परिवर्तन की जांच शुरू नहीं होगी। इसमें बहुत सुधार होता है
डिफ़ॉल्ट नीति ( ChangeDetectionStrategy.Default ) की तुलना में प्रदर्शन। निर्देशों में, हम @HostListener('eventName') डेकोरेटर के माध्यम से होस्ट तत्व की घटनाओं की भी सदस्यता ले सकते हैं।

मेरे व्यवहार में, अक्सर ऐसे मामले होते हैं जहां एक विशेष घटना के प्रसंस्करण की आवश्यकता होती है, यदि कोई शर्त पूरी होती है। यानी हैंडलर कुछ इस तरह दिखता है:

 class ComponentWithEventHandler { // ... onEvent(event: Event) { if (!this.condition) { return; } // Handling event ... } } 

यहां तक ​​कि अगर शर्त पूरी नहीं हुई है और वास्तव में कोई कार्रवाई नहीं हुई है, तब भी परिवर्तन सत्यापन चक्र शुरू किया जाएगा। लगातार घटनाओं के मामले में, जैसे कि scroll या mousemove , यह आवेदन के प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है।

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

सार्वभौमिक यूआई तत्वों के लिए ऐसे क्षण विशेष रूप से महत्वपूर्ण हैं। पृष्ठ पर उनमें से कई हो सकते हैं, और अनुप्रयोग बहुत जटिल हो सकते हैं और प्रदर्शन पर मांग कर सकते हैं।

आप ngZone को दरकिनार ngZone घटनाओं की सदस्यता लेकर स्थिति को ठीक कर सकते हैं, उदाहरण के लिए, Observable.fromEvent का उपयोग करते हुए और परिवर्तन के लिए मैन्युअल रूप से परिवर्तन करके जाँच शुरू कर सकते हैं changeDetectorRef.markForCheck() । हालांकि, यह अतिरिक्त कार्य का एक टन जोड़ता है और सुविधाजनक अंतर्निहित कोणीय उपकरण का उपयोग करना असंभव बनाता है।

यह कोई रहस्य नहीं है कि कोणीय आपको तथाकथित छद्म घटनाओं की सदस्यता लेने की अनुमति देता है, यह निर्दिष्ट करता है कि हम किन घटनाओं में रुचि रखते हैं। हम (keydown.enter)="onEnter($event)" और हैंडलर (और इसके साथ परिवर्तन चक्र) लिख सकते हैं, केवल तभी Enter किया जाएगा जब Enter कुंजी दबाया जाएगा। शेष प्रेस को अनदेखा किया जाएगा। इस लेख में, हम देखेंगे कि आप इवेंट हैंडलिंग को अनुकूलित करने के लिए कोणीय के समान दृष्टिकोण का उपयोग कैसे कर सकते हैं। और एक बोनस के रूप में, .prevent और .stop जोड़ें, जो डिफ़ॉल्ट व्यवहार को रद्द कर देगा और घटना को अपने आप .stop से रोक देगा।

EventManagerPlugin

कोणीय घटनाओं को संभालने के लिए EventManager वर्ग का उपयोग करता है। इसमें तथाकथित प्लगइन्स का एक सेट है जो अमूर्त EventManagerPlugin विस्तार करता है और इस घटना (नाम से) का समर्थन करने वाले प्लगइन के लिए इवेंट सदस्यता प्रसंस्करण को EventManagerPlugin । Angular के अंदर कई प्लगइन्स हैं, जिसमें HammerJS इवेंट हैंडलिंग और keydown.enter जैसी समग्र घटनाओं के लिए जिम्मेदार एक प्लगइन keydown.enter । यह कोणीय का आंतरिक कार्यान्वयन है, और यह दृष्टिकोण परिवर्तन के अधीन है। हालाँकि, इस समाधान के प्रसंस्करण पर मुद्दे के निर्माण के 3 साल बीत चुके हैं, और इस दिशा में कोई प्रगति नहीं हुई है:

https://github.com/angular/angular/issues/3929

हमारे लिए इसमें क्या दिलचस्प है? इस तथ्य के बावजूद कि ये वर्ग आंतरिक हैं और इनसे विरासत में नहीं लिया जा सकता है, प्लगइन्स के लिए निर्भरता को लागू करने के लिए जिम्मेदार टोकन सार्वजनिक है। इसका मतलब है कि हम अपने स्वयं के प्लगइन्स लिख सकते हैं और उनके साथ अंतर्निहित ईवेंट हैंडलिंग तंत्र का विस्तार कर सकते हैं।

यदि आप EventManagerPlugin के स्रोत कोड को EventManagerPlugin , तो आप देखेंगे कि हम इसे प्राप्त नहीं कर पाएंगे, अधिकांश भाग के लिए यह सार है और अपनी आवश्यकताओं को पूरा करने वाले अपने स्वयं के वर्ग को लागू करना आसान है:

https://github.com/angular/angular/blob/master/packages/platform-browser/src/dom/events/event_manager.ts#L92

मोटे तौर पर, प्लगइन यह निर्धारित करने में सक्षम होना चाहिए कि क्या वह इस घटना के साथ काम कर रहा है और एक इवेंट हैंडलर और वैश्विक हैंडलर ( body , window और document ) को जोड़ने में सक्षम होना चाहिए। हम संशोधक में रुचि रखते हैं .filter , .prevent और .stop उन्हें हमारे प्लगइन से बांधने के लिए, हम आवश्यक विधि supports :

 const FILTER = '.filter'; const PREVENT = '.prevent'; const STOP = '.stop'; class FilteredEventPlugin { supports(event: string): boolean { return ( event.includes(FILTER) || event.includes(PREVENT) || event.includes(STOP) ); } } 

तो EventManager समझ जाएगा कि घटनाओं के नाम पर कुछ EventManager हैं जो प्रसंस्करण के लिए हमारे प्लगइन को पारित करना होगा। फिर हमें इवेंट हैंडलर को जोड़ने की आवश्यकता है। हम वैश्विक संचालकों में रुचि नहीं रखते हैं, उनके मामले में ऐसे उपकरणों की आवश्यकता बहुत कम आम है, और कार्यान्वयन अधिक जटिल होगा। इसलिए, हम अपने मॉडिफायर्स को इवेंट के नाम से हटाते हैं और इसे EventManager को वापस कर EventManager ताकि यह प्रोसेसिंग के लिए सही बिल्ट-इन प्लग-इन EventManager :

 class FilteredEventPlugin { supports(event: string): boolean { // ... } addGlobalEventListener( element: string, eventName: string, handler: Function, ): Function { const event = eventName .replace(FILTER, '') .replace(PREVENT, '') .replace(STOP, ''); return this.manager.addGlobalEventListener(element, event, handler); } } 

एक नियमित तत्व पर एक घटना के मामले में, हमें अपना तर्क लिखना होगा। ऐसा करने के लिए, हम हैंडलर को लूप में लपेटते हैं और अपने EventManager बिना इवेंट को EventManager वापस EventManager , इसे ngZone बाहर कॉल करते हैं, परिवर्तन जाँच चक्र शुरू करने से बचने के लिए:

 class FilteredEventPlugin { supports(event: string): boolean { // ... } addEventListener( element: HTMLElement, eventName: string, handler: Function, ): Function { const event = eventName .replace(FILTER, '') .replace(PREVENT, '') .replace(STOP, ''); //     const filtered = (event: Event) => { // ... }; const wrapper = () => this.manager.addEventListener(element, event, filtered); return this.manager.getZone().runOutsideAngular(wrapper); } /* addGlobalEventListener(...): Function { ... } */ } 

इस स्तर पर, हमारे पास: घटना का नाम, घटना स्वयं, और वह तत्व जिस पर इसे सुना जा रहा है। यहां पहुंचने वाला हैंडलर इस घटना के लिए सौंपा गया हैंडलर नहीं है, लेकिन अंगुलर द्वारा अपने स्वयं के प्रयोजनों के लिए बनाई गई क्लोजर श्रृंखला का अंत है।

एक समाधान तत्व में एक विशेषता जोड़ना होगा, जो हैंडलर को कॉल करने या न करने के लिए जिम्मेदार है। कभी-कभी, एक निर्णय लेने के लिए, स्वयं घटना का विश्लेषण करना आवश्यक है: क्या डिफ़ॉल्ट कार्रवाई को रद्द कर दिया गया था, कौन सा तत्व घटना का स्रोत है, आदि। इसके लिए एक विशेषता पर्याप्त नहीं है, हमें एक फिल्टर फ़ंक्शन सेट करने का तरीका खोजने की आवश्यकता है जो एक घटना प्राप्त करता है और true या false रिटर्न देता true । फिर हम अपने हैंडलर का वर्णन इस प्रकार कर सकते हैं:

 const filtered = (event: Event) => { const filter = getOurHandler(some_arguments); if ( !eventName.includes(FILTER) || !filter || filter(event) ) { if (eventName.includes(PREVENT)) { event.preventDefault(); } if (eventName.includes(STOP)) { event.stopPropagation(); } this.manager.getZone().run(() => handler(event)); } }; 

निर्णय

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

मुख्य सेवा काफी सरल है और इसमें मानचित्र और सेटिंग, प्राप्ति और सफाई फिल्टर के लिए कुछ तरीके शामिल हैं:

 export type Filter = (event: Event) => boolean; export type Filters = {[key: string]: Filter}; class FilteredEventMainService { private elements: Map<Element, Filters> = new Map(); register(element: Element, filters: Filters) { this.elements.set(element, filters); } unregister(element: Element) { this.elements.delete(element); } getFilter(element: Element, event: string): Filter | null { const map = this.elements.get(element); return map ? map[event] || null : null; } } 

इस प्रकार, हम इस सेवा को प्लगइन में लागू कर सकते हैं और तत्व और घटना के नाम से एक फ़िल्टर प्राप्त कर सकते हैं। @HostListener के साथ संयोजन के रूप में उपयोग के लिए @HostListener हम एक और छोटी सेवा जोड़ते हैं जो घटक के साथ रहेगी और इसे हटाए जाने पर उपयुक्त फ़िल्टर साफ़ करें:

 export class EventFiltersService { constructor( @Inject(ElementRef) private readonly elementRef: ElementRef, @Inject(FilteredEventMainService) private readonly mainService: FilteredEventMainService, ) {} ngOnDestroy() { this.mainService.unregister(this.elementRef.nativeElement); } register(filters: Filters) { this.mainService.register(this.elementRef.nativeElement, filters); } } 

तत्वों में फ़िल्टर जोड़ने के लिए, आप एक समान निर्देश बना सकते हैं:

 class EventFiltersDirective { @Input() set eventFilters(filters: Filters) { this.mainService.register(this.elementRef.nativeElement, filters); } constructor( @Inject(ElementRef) private readonly elementRef: ElementRef, @Inject(FilteredEventMainService) private readonly mainService: FilteredEventMainService, ) {} ngOnDestroy() { this.mainService.unregister(this.elementRef.nativeElement); } } 

यदि घटक के अंदर घटनाओं को फ़िल्टर करने के लिए एक सेवा है, तो हम निर्देश के माध्यम से फ़िल्टर को उस पर लटकाए जाने की अनुमति नहीं देंगे। अंत में, यह लगभग हमेशा घटक को केवल उस तत्व के साथ लपेटकर किया जा सकता है जिसमें हमारा निर्देश सौंपा जाएगा। यह समझने के लिए कि कोई सेवा पहले से ही इस तत्व पर मौजूद है, हम वैकल्पिक रूप से इसे निर्देश में लागू करेंगे:

 class EventFiltersDirective { // ... constructor( @Optional() @Self() @Inject(FiltersService) private readonly filtersService: FiltersService | null, ) {} // ... } 

यदि यह सेवा मौजूद है, तो हम यह कहते हुए एक संदेश प्रदर्शित करेंगे कि यह निर्देश इसके लिए लागू नहीं है:

 class EventFiltersDirective { @Input() set eventFilters(filters: Filters) { if (this.eventFiltersService === null) { console.warn(ALREADY_APPLIED_MESSAGE); return; } this.mainService.register(this.elementRef.nativeElement, filters); } // ... } 

व्यावहारिक अनुप्रयोग

सभी वर्णित कोड स्टैकब्लिट्ज़ पर पाए जा सकते हैं:

https://stackblitz.com/edit/angular-event-filter

उपयोग के उदाहरण के रूप में, एक काल्पनिक select वहां दिखाया गया है - एक मोडल विंडो के अंदर एक घटक - और इसके ड्रॉपडाउन की भूमिका में एक संदर्भ मेनू। संदर्भ मेनू के मामले में, यदि आप किसी भी कार्यान्वयन की जांच करते हैं, तो आप देखेंगे कि व्यवहार हमेशा निम्न होता है: जब आप किसी आइटम पर होवर करते हैं, तो यह फ़ोकस करता है, जब आप कीबोर्ड पर तीर दबाते हैं, तो आइटम के माध्यम से फ़ोकस हो जाता है, लेकिन यदि आप माउस को स्थानांतरित करते हैं, तो फ़ोकस तत्व पर लौटता है माउस पॉइंटर के नीचे स्थित है। ऐसा लगता है कि इस व्यवहार को लागू करना आसान है, हालांकि, mousemove घटना के लिए अनावश्यक प्रतिक्रियाएं दर्जनों बेकार परिवर्तन चक्रों को ट्रिगर कर सकती हैं। फ़िल्टर के रूप में घटना के target तत्व के फ़ोकस के लिए एक चेक सेट करके, हम इन अनावश्यक ट्रिगरिंग को काट सकते हैं, केवल उन लोगों को छोड़कर जो वास्तव में फोकस को ले जाते हैं।

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

@HostListener('keydown.esc.filtered.stop') , जब @HostListener('keydown.esc.filtered.stop') : () => this.opened ।

चूंकि select कई ध्यान देने योग्य तत्वों के साथ एक घटक है, इसलिए फोकस पॉपअप घटनाओं के माध्यम से इसके सामान्य फोकस को ट्रैक करना संभव है। वे फ़ोकस में सभी परिवर्तनों के साथ घटित होंगे, जिसमें वे भी शामिल हैं जो घटक की सीमाओं को नहीं छोड़ते हैं। इस ईवेंट में एक relatedTarget फ़ील्ड है जो relatedTarget कि फ़ोकस कहां चलता है इसका विश्लेषण करने के बाद, हम समझ सकते हैं कि क्या हमारे घटक के लिए blur घटना का एनालॉग कॉल करना है:

 class SelectComponent { // ... @HostListener('focusout.filtered') onBlur() { this.opened = false; } // ... } 

फिल्टर, एक ही समय में, इस तरह दिखता है:

 const focusOutFilter = ({relatedTarget}: FocusEvent) => !this.elementRef.nativeElement.contains(relatedTarget); 

निष्कर्ष

दुर्भाग्य से, कोणीय में यौगिक कीस्ट्रोक्स का अंतर्निहित प्रसंस्करण अभी भी NgZone में शुरू होगा, जिसका अर्थ है कि यह परिवर्तनों के लिए जाँच करेगा। यदि हम चाहते थे, तो हम अंतर्निहित प्रसंस्करण का सहारा नहीं ले सकते थे, लेकिन प्रदर्शन लाभ छोटा होगा, और उन्नयन के दौरान कोणीय की आंतरिक "रसोई" में होने वाली क्षति हो सकती है। इसलिए, हमें या तो समग्र घटना का परित्याग करना चाहिए, या सीमा ऑपरेटर के समान एक फिल्टर का उपयोग करना चाहिए और बस हैंडलर को कॉल नहीं करना चाहिए जहां यह प्रासंगिक नहीं है।

कोणीय के आंतरिक घटना प्रसंस्करण में खींचना एक साहसिक उपक्रम है, क्योंकि आंतरिक कार्यान्वयन भविष्य में बदल सकता है। यह हमें लेख के दूसरे खंड में दिए गए अपडेट, विशेष रूप से, GitHub पर कार्य का अनुसरण करने के लिए बाध्य करता है। लेकिन अब हम आसानी से हैंडलर के निष्पादन को फ़िल्टर कर सकते हैं और परिवर्तनों के लिए जाँच शुरू कर सकते हैं; अब हमारे पास एक सदस्यता की घोषणा करते समय इवेंट प्रोसेसिंग के विशिष्ट तरीके से stopPropagation लिए आसानी से stopPropagation और stopPropagation विधियों को लागू करने का अवसर है। भविष्य से, सजावटकर्ताओं का उपयोग करके उनके ठीक बगल में @HostListener लिए फ़िल्टर घोषित करना अधिक सुविधाजनक होगा। अगले लेख में, मैंने कई सज्जाकारों के बारे में बात करने की योजना बनाई है जो हमने घर पर बनाए हैं, और इस समाधान को लागू करने का प्रयास करते हैं।