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

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

कार्य

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

समाधान के लिए खोजें

Google ने "एंगुलरजस सशर्त रूटिंग" के अनुरोध पर जारी की गई एकमात्र उपयोगी चीज स्टैकओवरफ्लो पर यह प्रश्न है । दो समाधान प्रस्तावित किए गए थे:

पहले सर्वर से 401 स्थिति भेजना और $ http सेवा के माध्यम से इसे रोकना है - प्रत्येक संरक्षित पृष्ठ से सर्वर के लिए एक अनुरोध मान लिया गया है। हो सकता है कि यह किसी के लिए उपयुक्त हो, लेकिन मेरे लिए नहीं - मैं एक बार डेटा डाउनलोड करता हूं और न ही क्लाइंट पर राउटिंग के लिए सर्वर खत्म करना चाहता हूं।

दूसरा संदेश $ मार्गक्रेस्टस्टार्ट को रोकना है, जहां हम जा रहे हैं, यह देखें कि क्या प्राधिकरण है और यदि नहीं, तो पुनर्निर्देशित करें। वैकल्पिक रूप से, $ स्कोप के माध्यम से पथ परिवर्तन के लिए सुनो। $ वॉच (फ़ंक्शन () {$ $ स्थान.पाथ ();};) इस समाधान के नुकसान हैं:

1. $ मार्ग परिवर्तन के मामले में, अगली वस्तु रूटिंग मार्ग प्रदान नहीं करती है; यह समझना बहुत सुविधाजनक नहीं है कि हम कहां जा रहे हैं; इस संदेश को गैर-मौजूद पृष्ठों से रीडायरेक्ट पर भी फेंक दिया जाएगा, परिणामस्वरूप, रूटिंग की स्थितियों में अभिव्यक्तियाँ बहुत सुंदर नहीं होंगी, टेम्प्लेट के नाम, नियंत्रकों के नाम और अन्य अजीब चीजों से बंधे होंगे।
2. यदि आपको डेटा लोड करने की आवश्यकता है, तो मेरे मामले में, डाउनलोड के अंत तक रूटिंग में देरी करने का कोई तरीका नहीं है। इस मामले में, रूटिंग उपयोगकर्ता प्रोफ़ाइल में डेटा पर ही निर्भर हो सकता है, उदाहरण के लिए, इसमें एक नया सुपर ऑफ़र है और आपको सब कुछ छोड़ने और तत्काल इस ऑफ़र के पृष्ठ पर जाने की आवश्यकता है।

मुझे अलग-अलग "डाउनलोड पृष्ठ" पर पुनर्निर्देशित करने के लिए अनावश्यक डेटा के साथ एक विचार था, डेटा को अपलोड करने और परिणामों के अनुसार रीडायरेक्ट करने के लिए, लेकिन सबसे पहले, रूटिंग लॉजिक दो स्थानों में फैला हुआ है - एक में हम पथ को देखते हैं, दूसरे डेटा में; दूसरे, उपयोगकर्ता के पास इतिहास में यह मध्यवर्ती पृष्ठ होगा। आप $ location.replace () का उपयोग करके इतिहास को मिटा सकते हैं, लेकिन अगर किसी कारण से डाउनलोड में देरी हो रही है और उपयोगकर्ता के पास वापस क्लिक करने का समय है, तो गलत पृष्ठ मिटा दिया जाएगा, लेकिन यह दूसरे पृष्ठ से भी सही हो जाएगा, आपको किसी तरह इसे संसाधित करने की आवश्यकता है मामला जो समाधान में सरलता नहीं जोड़ता है। तीसरा, हमें उस जगह को याद रखने की जरूरत है, जहां हम इसे सही ढंग से ठीक करने के लिए गए थे, "दूसरी" स्थिति को ध्यान में रखते हुए। इस फैसले ने मुझे प्रेरित नहीं किया और मैंने खोज जारी रखी।

निर्णय

AngularJS दिलचस्प नाम $ q के साथ एक सेवा प्रदान करता है। आप प्रलेखन में पढ़ सकते हैं कि क्यू और स्थगित / वादा विनिर्देश एक काफी सरल और दिलचस्प अवधारणा है। संक्षेप में, हम सेवा को एक विशेष सुविधा बनाने के लिए कहते हैं

var defered = $q.defer();


इस ऑब्जेक्ट से, हम वादा ऑब्जेक्ट प्राप्त करते हैं और अपने क्लाइंट को कोड देते हैं

return defered.promise;


क्लाइंट को ऑपरेशन सफलता और विफलता के कॉलबैक के वादे पर लटके हुए हैं

promise.then(function (result) {...}, function (reason) {...});


अब जब हम अपनी सुविधानुसार करते हैं

defered.resolve(result);


या

defered.reject();


क्लाइंट को उपयुक्त कॉलबैक कहा जाता है। नियमित कॉलबैक से बेहतर क्या है? वादों को जंजीरों में जोड़ा जा सकता है (विवरण के लिए, प्रलेखन देखें) और, जो मेरे काम के लिए महत्वपूर्ण है, कई AngularJS सेवाएं उनके साथ काम कर सकती हैं, जिसमें $ राऊटरपॉइडर भी शामिल हैं आप मार्ग कॉन्फ़िगरेशन में एक संकल्प क्षेत्र निर्दिष्ट कर सकते हैं और एक फ़ंक्शन पास कर सकते हैं - एक वादा । इसके अलावा, यदि यह फ़ंक्शन एक ऑब्जेक्ट लौटाता है जो एक वादा नहीं है, तो इसे एक ऐसे वादे के रूप में व्याख्या किया जाएगा जो पहले ही हल हो चुका है। वादा पूरा होने तक मार्ग प्रतीक्षा करेगा, और यदि अस्वीकार होता है, तो यह पूरी तरह से रद्द कर दिया जाएगा। फिर सब कुछ सरल है - हम एक फ़ंक्शन लिखते हैं जो डेटा लोड करता है, यदि आवश्यक हो, तो सभी चेक और रीडायरेक्ट करता है। यदि आपको डेटा लोड करने की आवश्यकता है, तो वादे को वापस कर दिया जाता है, यदि आपको रीडायरेक्ट करने की आवश्यकता है, तो वादे को इससे पहले पुनर्निर्देशित किया जाता है ताकि पुराना मार्ग व्यर्थ न हो।

समाधान कोड:

 'use strict'; var app = angular.module('app', []) .config(['$routeProvider', function($routeProvider) { $routeProvider .when('/', { templateUrl: "login.html", controller: LoginController }) .when('/private', { templateUrl: "private.html", controller: PrivateController, resolve: { factory: checkRouting } }) .when('/private/anotherpage', { templateUrl:"another-private.html", controller: AnotherPriveController, resolve: { factory: checkRouting } }) .otherwise({ redirectTo: '/' }); }]); var checkRouting= function ($q, $rootScope, $location) { if ($rootScope.userProfile) { return true; } else { var defered = $q.defer(); $http.post("/loadUserProfile", { userToken: "blah" }) .success(function (response) { $rootScope.userProfile = response.userProfile; defered.resolve(true); }) .error(function () { defered.reject(); $location.path("/"); }); return defered.promise; } }; 

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

अद्यतन: टिप्पणियों ने मुझे $ http.post () से एक श्रृंखला में वादों के प्रसारण के साथ कोड लिखने के लिए प्रोत्साहित किया, जो $ http सेवा के अन्य तरीकों की तरह एक वादा लौटाता है। वादों के इस तरह के प्राकृतिक उपयोग के साथ, हमें प्रक्रिया का एक शांत स्पष्ट विभाजन चरणों और कार्यों में एक स्पष्ट अनुबंध के साथ मिलता है।

वादे की श्रृंखला का तंत्र यह है: तत्कालीन वादा विधि एक और "व्युत्पन्न" वादा लौटाती है, जो कि तब निर्दिष्ट किए गए हैंडलर में से किसी एक रिवाल्वर या रीजेक्स द्वारा लौटाए गए मूल्य के साथ हल किया जाता है, या यह पता लगाया जाएगा कि क्या हैंडलर में से एक अपवाद फेंकता है। इसके अलावा, यदि वापसी मूल्य खुद ही वादा है, तो इसका परिणाम व्युत्पन्न वादे के परिणाम को निर्धारित करेगा। इसलिए, एक व्युत्पन्न वादा दर्ज करने के लिए, यह $ q.reject () वापस करने के लिए पर्याप्त है।

परिणामस्वरूप, समाधान इस तरह दिखता है:

 //    ,   resolve . var checkRouting = function ($q, $rootScope, $http, $location, localStorageService) { //     function redirect(path) { if ($location.path() != path) { $location.path(path); //  . return $q.reject(); //   . } else { return true; //   . } } return getUserDataPromise($q, $rootScope, $http, localStorageService) .then(function (userData) { //       . if (userData.sales.lenght > 0) { return redirect("/sales"); //   ,   ! } else { return true; //  ,  . } }, function (reason) { //      . console.error(reason); //     ; ) return redirect("/"); }); }; //  ,      userData,  . var getUserDataPromise = function ($q, $rootScope, $http, localStorageService) { if ($rootScope.userData) { return $q.when($rootScope.userData); //    ( ) . } else { var userToken = localStorageService.get("userToken"); if (!userToken) { return $q.reject("No user token."); //     . } else { //  ,        , //  ,     . return $http.post("/loadUserData", { userToken: userToken }) .then(function (result) { if (result.data.userData) { $rootScope.userData = result.data.userData; return result.data.userData; } else { return $q.reject("Got response from server but without user data."); } }, function (reason) { return $q.reject("Error requesting server: " + reason); }); } } };