इसके लिए Ngrx / प्रभावों का उपयोग बंद करें

कभी-कभी कार्यक्षमता का सरलतम कार्यान्वयन अंततः अच्छे से अधिक समस्याएं पैदा करता है, केवल कहीं और जटिलता बढ़ जाती है। अंतिम परिणाम एक दांतेदार वास्तुकला है जिसे कोई छूना नहीं चाहता है।

Ngrx / store एक कोणीय पुस्तकालय है जो व्यक्तिगत कार्यों की जटिलता को समाहित करने में मदद करता है। एक कारण यह है कि ngrx / store कार्यात्मक प्रोग्रामिंग को गले लगाता है, जो यह बताता है कि एक फ़ंक्शन के अंदर क्या किया जा सकता है ताकि इसके बाहर अधिक तर्क-वितर्क हो सके। Ngrx / store में, reducers (बाद में reducers के रूप में संदर्भित), चयनकर्ता (बाद में selectors के रूप में संदर्भित) और RxJS ऑपरेटर जैसी चीजें शुद्ध कार्य हैं।

शुद्ध कार्यों का परीक्षण, डिबग, विश्लेषण, समानांतर और संयोजन करना आसान है। एक समारोह साफ है अगर:

• एक ही इनपुट के साथ, यह हमेशा एक ही आउटपुट देता है;
• कोई साइड इफेक्ट नहीं।

साइड इफेक्ट्स से बचा नहीं जा सकता है, लेकिन वे ngrx / store में अलग-थलग हैं, इसलिए बाकी एप्लिकेशन में शुद्ध कार्य शामिल हो सकते हैं।

साइड इफेक्ट

जब उपयोगकर्ता प्रपत्र सबमिट करता है, तो हमें सर्वर पर परिवर्तन करने की आवश्यकता होती है। सर्वर को बदलना और क्लाइंट को जवाब देना एक साइड इफेक्ट है। इस घटक में संभाला जा सकता है:

this.store.dispatch({ type: 'SAVE_DATA', payload: data, }); this.saveData(data) // POST    .pipe(map(res => this.store.dispatch({ type: 'DATA_SAVED' }))) .subscribe(); 

यह अच्छा होगा यदि हम घटक के अंदर केवल एक्शन (इसके बाद की कार्रवाई) को भेज सकते हैं जब उपयोगकर्ता फॉर्म सबमिट करता है और साइड इफेक्ट को कहीं और संभालता है।

Ngrx / स्टोर में साइड इफेक्ट से निपटने के लिए Ngrx / इफेक्ट्स मिडलवेयर है। यह देखने योग्य थ्रेड में सबमिट की गई क्रियाओं को सुनता है, साइड इफेक्ट्स करता है, और तुरंत या एसिंक्रोनस रूप से नए एक्शन देता है। लौटी हुई कार्रवाइयाँ reducer को दी जाती हैं।

RxJS तरीके से साइड इफेक्ट्स को हैंडल करने की क्षमता कोड को क्लीनर बनाती है। घटक से प्रारंभिक कार्रवाई SAVE_DATA भेजने के बाद, आप बाकी को संभालने के लिए एक प्रभाव वर्ग बनाते हैं:

 @Effect() saveData$ = this.actions$.pipe( ofType('SAVE_DATA'), pluck('payload'), switchMap(data => this.saveData(data)), map(res => ({ type: 'DATA_SAVED' })), ); 

यह कार्यों को भेजने और अवलोकन करने के लिए सदस्यता लेने से पहले घटक के संचालन को सरल करता है।

Ngrx / प्रभावों का दुरुपयोग करने में आसान है

Ngrx / प्रभाव एक बहुत शक्तिशाली समाधान है, इसलिए इसका दुरुपयोग करना आसान है। यहाँ कुछ सामान्य ngrx / स्टोर विरोधी पैटर्न हैं जिन्हें Ngrx / प्रभाव सरल करता है:

1. डुप्लिकेट स्थिति

मान लीजिए कि आप किसी प्रकार के मल्टीमीडिया एप्लिकेशन पर काम कर रहे हैं, और आपके पास राज्य के पेड़ में निम्नलिखित गुण हैं:

 export interface State { mediaPlaying: boolean; audioPlaying: boolean; videoPlaying: boolean; } 

चूंकि ऑडियो एक प्रकार का मीडिया है, जब भी audioPlaying सही होती है, mediaPlaying भी सही होनी चाहिए। तो यहाँ सवाल है: "मैं कैसे सुनिश्चित करता हूँ कि मीडियाप्लेइंग अपडेट की गई है जब ऑडियोप्लेइंग अपडेट की गई हो?"

अमान्य उत्तर : Ngrx / प्रभाव का उपयोग करें!

 @Effect() playMediaWithAudio$ = this.actions$.pipe( ofType('PLAY_AUDIO'), map(() => ({ type: 'PLAY_MEDIA' })), ); 

सही उत्तर : यदि mediaPlaying की स्थिति का अनुमान पूरी तरह से राज्य के पेड़ के दूसरे हिस्से द्वारा लगाया जाता है, तो यह एक सच्ची स्थिति नहीं है। यह एक व्युत्पन्न अवस्था है। यह चयनकर्ता का है, स्टोर का नहीं।

 audioPlaying$ = this.store.select('audioPlaying'); videoPlaying$ = this.store.select('videoPlaying'); mediaPlaying$ = combineLatest(this.audioPlaying$, this.videoPlaying$).pipe( map(([audioPlaying, videoPlaying]) => audioPlaying || videoPlaying), ); 

अब हमारी स्थिति स्वच्छ और सामान्य बनी रह सकती है, और हम किसी चीज के लिए Ngrx / प्रभाव का उपयोग नहीं करते हैं जो कि दुष्प्रभाव नहीं है।

2. रिड्यूसर के साथ क्रिया करना

कल्पना करें कि आपके राज्य के पेड़ में ये गुण हैं:

 export interface State { items: { [index: number]: Item }; favoriteItems: number[]; } 

तब उपयोगकर्ता आइटम को हटा देता है। जब हटाए गए अनुरोध को वापस किया जाता है, तो हमारे आवेदन की स्थिति को अपडेट करने के लिए DELETE_ITEM_SUCCESS कार्रवाई भेजी जाती है। items रिड्यूसर में, items ऑब्जेक्ट से एक व्यक्तिगत Item हटा दिया जाता है। लेकिन अगर यह तत्व पहचानकर्ता पसंदीदाइटेम सरणी में था, तो यह जिस तत्व को संदर्भित करता है वह अनुपस्थित होगा। तो सवाल यह है कि, DELETE_ITEM_SUCCESS कार्रवाई भेजते समय मैं यह कैसे सुनिश्चित कर सकता हूं कि पहचानकर्ता को favoriteItems DELETE_ITEM_SUCCESS से हटा दिया गया है?

अमान्य उत्तर : Ngrx / प्रभाव का उपयोग करें!

 @Effect() removeFavoriteItemId$ = this.actions$.pipe( ofType('DELETE_ITEM_SUCCESS'), map(() => ({ type: 'REMOVE_FAVORITE_ITEM_ID' })), ); 

इसलिए, अब हमारे पास दो कार्रवाई एक के बाद एक भेजी जाएंगी, और दो reducers एक के बाद एक नए राज्य लौटाएंगे।

सही उत्तर : DELETE_ITEM_SUCCESS को items DELETE_ITEM_SUCCESS और favoriteItems दोनों DELETE_ITEM_SUCCESS द्वारा संसाधित किया जा सकता है।

 export function favoriteItemsReducer(state = initialState, action: Action) { switch (action.type) { case 'REMOVE_FAVORITE_ITEM': case 'DELETE_ITEM_SUCCESS': const itemId = action.payload; return state.filter(id => id !== itemId); default: return state; } } 

कार्रवाई का लक्ष्य अलग होना है कि राज्य को कैसे बदलना चाहिए। क्या हुआ DELETE_ITEM_SUCCESS । Reducers का कार्य राज्य में एक समान परिवर्तन का कारण है।

favoriteItems से एक पहचानकर्ता को हटाना Item को हटाने का कोई साइड इफेक्ट नहीं है। पूरी प्रक्रिया पूरी तरह से सिंक्रनाइज़ है और इसे reducers द्वारा संसाधित किया जा सकता है। Ngrx / प्रभावों की आवश्यकता नहीं है।

3. घटक के लिए डेटा का अनुरोध करें

आपके घटक को स्टोर से डेटा की आवश्यकता है, लेकिन पहले आपको इसे सर्वर से प्राप्त करना होगा। सवाल यह है कि हम डेटा को स्टोर में कैसे रख सकते हैं ताकि घटक इसे प्राप्त कर सके?

दर्दनाक तरीका : Ngrx / प्रभाव का उपयोग करें!

घटक में, हम एक कार्रवाई भेजकर अनुरोध शुरू करते हैं:

 ngOnInit() { this.store.dispatch({ type: 'GET_USERS' }); } 

प्रभाव वर्ग में, हम GET_USERS :

 @Effect getUsers$ = this.actions$.pipe( ofType('GET_USERS'), withLatestFrom(this.userSelectors.needUsers$), filter(([action, needUsers]) => needUsers), switchMap(() => this.getUsers()), map(users => ({ type: 'RECEIVE_USERS', users })), ); 

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

 ngOnDestroy() { this.store.dispatch({ type: 'CANCEL_GET_USERS' }); } 

अब प्रभाव वर्ग में हम दोनों क्रियाओं को सुनते हैं:

 @Effect getUsers$ = this.actions$.pipe( ofType('GET_USERS', 'CANCEL_GET_USERS'), withLatestFrom(this.userSelectors.needUsers$), filter(([action, needUsers]) => needUsers), map(([action, needUsers]) => action), switchMap( action => action.type === 'CANCEL_GET_USERS' ? of() : this.getUsers().pipe(map(users => ({ type: 'RECEIVE_USERS', users }))), ), ); 

सब ठीक है। अब एक और डेवलपर एक घटक जोड़ता है जिसे उसी HTTP अनुरोध की आवश्यकता होती है (हम अन्य घटकों के बारे में कोई धारणा नहीं बनाएंगे)। घटक एक ही क्रिया को एक ही स्थान पर भेजता है। यदि दोनों घटक एक ही समय में सक्रिय होते हैं, तो पहला घटक इसे आरंभ करने के लिए एक HTTP अनुरोध शुरू करता है। जब दूसरा घटक शुरू किया जाता है, तो कुछ भी अतिरिक्त नहीं होगा, क्योंकि needUsers false । अद्भुत!

फिर, जब पहला घटक नष्ट हो जाता है, तो वह CANCEL_GET_USERS भेज CANCEL_GET_USERS । लेकिन दूसरे घटक को अभी भी इस डेटा की आवश्यकता है। हम किसी अनुरोध को रद्द होने से कैसे रोक सकते हैं? शायद हम सभी ग्राहकों का काउंटर शुरू कर देंगे? मैं इसे लागू नहीं करने जा रहा हूं, लेकिन मुझे लगता है कि आप इस बिंदु को समझ गए हैं। हमें संदेह होने लगा है कि इन डेटा निर्भरता को प्रबंधित करने का एक बेहतर तरीका है।

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

इस विशेष परिदृश्य के लिए मुझे जो सबसे अच्छी मदद मिली, वह है यह बेहतरीन पोस्ट । उनके उदाहरण में, callApiY आवश्यक है कि callApiX पहले ही पूरा कर लिया जाए। मैंने टिप्पणियों को हटा दिया ताकि यह कम डराने वाला लगे, लेकिन अधिक जानने के लिए मूल पोस्ट पढ़ने के लिए स्वतंत्र महसूस करें:

 @Effect() actionX$ = this.actions$.pipe( ofType('ACTION_X'), map(toPayload), switchMap(payload => this.api.callApiX(payload).pipe( map(data => ({ type: 'ACTION_X_SUCCESS', payload: data })), catchError(err => of({ type: 'ACTION_X_FAIL', payload: err })), ), ), ); @Effect() actionY$ = this.actions$.pipe( ofType('ACTION_Y'), map(toPayload), withLatestFrom(this.store.select(state => state.someBoolean)), switchMap(([payload, someBoolean]) => { const callHttpY = v => { return this.api.callApiY(v).pipe( map(data => ({ type: 'ACTION_Y_SUCCESS', payload: data, })), catchError(err => of({ type: 'ACTION_Y_FAIL', payload: err, }), ), ); }; if (someBoolean) { return callHttpY(payload); } return of({ type: 'ACTION_X', payload }).merge( this.actions$.pipe( ofType('ACTION_X_SUCCESS', 'ACTION_X_FAIL'), first(), switchMap(action => { if (action.type === 'ACTION_X_FAIL') { return of({ type: 'ACTION_Y_FAIL', payload: 'Because ACTION_X failed.', }); } return callHttpY(payload); }), ), ); }), ); 

अब आवश्यकता जोड़ें कि HTTP अनुरोध रद्द कर दिया जाना चाहिए जब घटकों को अब उनकी आवश्यकता नहीं है, और यह और भी जटिल हो जाएगा।

  ।  ।  । 

तो, डेटा निर्भरता प्रबंधन के साथ इतनी समस्याएं क्यों हैं जब RxJS को वास्तव में आसान बनाना चाहिए?

हालाँकि सर्वर से आने वाला डेटा तकनीकी रूप से एक साइड इफ़ेक्ट है, लेकिन यह मुझे नहीं लगता कि Ngrx / इफ़ेक्ट इसे संभालने का सबसे अच्छा तरीका है।

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

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

  ।  ।  । 

कम दर्दनाक तरीका : घटक अवलोकन के माध्यम से उन्हें सदस्यता देकर डेटा में अपनी रुचि दर्ज करेगा।

हम वे अवलोकन योग्य बनाएंगे जिनमें आवश्यक HTTP अनुरोध शामिल हैं। हम देखेंगे कि प्रभाव के माध्यम से ऐसा करने के बजाय, शुद्ध RxJS का उपयोग करके एक-दूसरे पर निर्भर कई सदस्यताएँ और क्वेरी श्रृंखलाओं को प्रबंधित करना कितना आसान है।

सेवा में ये देखने योग्य बनाएं:

 requireUsers$ = this.store.pipe( select(selectNeedUser), filter(needUsers => needUsers), tap(() => this.store.dispatch({ type: 'GET_USERS' })), switchMap(() => this.getUsers()), tap(users => this.store.dispatch({ type: 'RECEIVE_USERS', users })), finalize(() => this.store.dispatch({ type: 'CANCEL_GET_USERS' })), share(), ); users$ = muteFirst( this.requireUsers$.pipe(startWith(null)), this.store.pipe(select(selectUsers)), ); 

users$ सदस्यता आवश्यकता के requireUsers$ और this.store.pipe(select(selectUsers)) दोनों को प्रेषित की जाएगी, लेकिन डेटा केवल इस से प्राप्त किया जाएगा this.store.pipe(select(selectUsers)) ( muteFirst कार्यान्वयन muteFirst और फिक्स्ड muteFirst उसके परीक्षण के साथ।)

घटक में:

 ngOnInit() { this.users$ = this.userService.users$; } 

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

डेटा निर्भरता श्रृंखला को इस तरह संसाधित किया जा सकता है:

 requireUsers$ = this.store.pipe( select(selectNeedUser), filter(needUsers => needUsers), tap(() => this.store.dispatch({ type: 'GET_USERS' })), switchMap(() => this.getUsers()), tap(users => this.store.dispatch({ type: 'RECEIVE_USERS', users })), share(), ); users$ = muteFirst( this.requireUsers$.pipe(startWith(null)), this.store.pipe(select(selectUsers)), ); requireUsersExtraData$ = this.users$.pipe( withLatestFrom(this.store.pipe(select(selectNeedUsersExtraData))), filter(([users, needData]) => Boolean(users.length) && needData), tap(() => this.store.dispatch({ type: 'GET_USERS_EXTRA_DATA' })), switchMap(() => this.getUsers()), tap(users => this.store.dispatch({ type: 'RECEIVE_USERS_EXTRA_DATA', users, }), ), share(), ); public usersExtraData$ = muteFirst( this.requireUsersExtraData$.pipe(startWith(null)), this.store.pipe(select(selectUsersExtraData)), ); 

इस विधि के साथ उपरोक्त विधि की समानांतर तुलना यहां दी गई है:

शुद्ध अवलोकन योग्य उपयोग करने के लिए कोड की कम लाइनों की आवश्यकता होती है और यह पूरी श्रृंखला में डेटा निर्भरता से स्वचालित रूप से सदस्यता समाप्त हो जाती है। (मैंने finalize कथनों को छोड़ दिया, जो मूल रूप से तुलना को अधिक समझने के लिए शामिल किए गए थे, लेकिन यहां तक ​​कि उनके बिना, प्रश्न अभी भी तदनुसार होंगे।)

निष्कर्ष

Ngrx / प्रभाव एक महान उपकरण है! लेकिन इसका उपयोग करने से पहले इन सवालों पर विचार करें:

• क्या यह वास्तव में साइड इफेक्ट है?
• क्या Ngrx / प्रभाव ऐसा करने का सबसे अच्छा तरीका है?