SWR की मूल अवधारणाएँ: Stale-While-Revalidate

SWR का अर्थ है पुराना डेटा देते हुए पुनः सत्यापन, जो RFC 5861 में परिभाषित HTTP कैश रणनीति है। इस रणनीति में उपयोगकर्ता को पुराना (कैश किया हुआ) डेटा तुरंत दिखाया जाता है, फिर पृष्ठभूमि में उसका पुनः सत्यापन किया जाता है और नया डेटा आने पर इंटरफ़ेस अपडेट कर दिया जाता है।

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

पारंपरिक लोडिंग तरीकों में हर बार पृष्ठ बदलने पर उपयोगकर्ताओं को घूमता हुआ संकेतक दिखाई देता है। SWR के साथ उन्हें अंतिम ज्ञात डेटा तुरंत दिखाई देता है और डेटा बदलने पर इंटरफ़ेस पृष्ठभूमि में बिना किसी बाधा के अपडेट हो जाता है।

इससे अनुप्रयोग काफ़ी तेज़ महसूस होते हैं और लोडिंग स्थितियों से होने वाला मानसिक व्यवधान कम होता है।

SWR इन स्थितियों में डेटा का पुनः सत्यापन अपने-आप करता है: ब्राउज़र विंडो पर फिर से फ़ोकस आने पर (जब उपयोगकर्ता दूसरे टैब पर जाकर वापस आता है), ऑफ़लाइन होने के बाद नेटवर्क कनेक्शन बहाल होने पर, स्पष्ट रूप से mutate() कॉल किए जाने पर, या refreshInterval टाइमर चलने पर।

ये स्वचालित ट्रिगर डेवलपर को डेटा दोबारा लाने का तर्क स्वयं प्रबंधित किए बिना डेटा को ताज़ा रखते हैं।

SWR की key कई स्थितियों में से किसी एक में हो सकती है: loading (कोई कैश किया हुआ डेटा नहीं है और पहली बार डेटा लाया जा रहा है), revalidating (कैश किया हुआ डेटा मौजूद है और पृष्ठभूमि में उसे ताज़ा किया जा रहा है), error (अनुरोध विफल हो गया है), या success (नया डेटा उपलब्ध है)।

इन स्थितियों को समझने से आपको सटीक लोडिंग कंकाल और त्रुटि इंटरफ़ेस बनाने में सहायता मिलती है।

SWR अनुरोध की key (आमतौर पर URL स्ट्रिंग) के आधार पर वैश्विक मेमोरी कैश बनाए रखता है। जो भी घटक उसी key का अनुरोध करता है, उसे वही कैश किया हुआ मान मिलता है और वह उसी पुनः सत्यापन चक्र में भाग लेता है।

डुप्लिकेट अनुरोधों को अपने-आप हटाने की इस सुविधा का अर्थ है कि 10 घटक समान key के साथ useSWR कॉल कर सकते हैं और फिर भी नेटवर्क अनुरोध केवल एक ही भेजा जाएगा।

SWR कैश प्रबंधन के तर्क को वास्तविक डेटा लाने की प्रक्रिया से अलग रखता है। आप एक fetcher फ़ंक्शन देते हैं: ऐसा async फ़ंक्शन जो key स्वीकार करता है और डेटा लौटाता है।

fetcher को बदला जा सकता है: fetch, axios, graphql-request या किसी भी async डेटा स्रोत का उपयोग करें। fetcher चाहे जैसे काम करे, SWR कैशिंग और पुनः सत्यापन संभालता है।

अपने ऐप को ऐसे value prop वाले SWRConfig में रैप करें, जिसमें fetcher फ़ंक्शन हो: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}। fetcher तर्क छोड़ने वाली हर useSWR कॉल इस वैश्विक डिफ़ॉल्ट का उपयोग करती है।

इससे API कॉन्फ़िगरेशन (बेस URL और प्रमाणीकरण हेडर) को हर हुक कॉल में दोहराने के बजाय एक ही जगह पर केंद्रीकृत किया जा सकता है।

पारंपरिक तरीका लोडिंग, डेटा और त्रुटि की स्थितियों को मैन्युअल रूप से संभालने के लिए useEffect + useState का उपयोग करता है। SWR इन सबकी जगह एकल हुक कॉल देता है, जो कैशिंग, डुप्लिकेट अनुरोधों को हटाना, पृष्ठभूमि में ताज़ा करना और त्रुटि पर दोबारा प्रयास करना अपने-आप संभालता है।

कोड में कमी काफ़ी बड़ी होती है: डेटा लाने वाला सामान्य घटक 20 से अधिक पंक्तियों से घटकर 3 पंक्तियों का रह जाता है।

key किसी अनुरोध की विशिष्ट पहचान करती है। सरल मामलों में URL स्ट्रिंग का उपयोग करें। पैरामीटर वाले अनुरोधों के लिए ऐरे key का उपयोग करें: [url, params], जहाँ params एक स्थिर ऑब्जेक्ट या स्ट्रिंग हो। null अनुरोध को बंद कर देता है।

अच्छा key डिज़ाइन यह सुनिश्चित करता है कि संबंधित अनुरोध कैश प्रविष्टियाँ साझा करें और असंबंधित अनुरोधों की key आपस में न टकराएँ।

SWR पुनः सत्यापन को समझदारी से संभालता है: dedupingInterval (डिफ़ॉल्ट 2 सेकंड) एक साथ कई घटक माउंट होने पर अनेक पुनः सत्यापनों को एक ही समय में शुरू होने से रोकता है। डुप्लिकेशन-रोधक अवधि के भीतर प्रत्येक key के लिए केवल एक अनुरोध भेजा जाता है।

इससे बड़े घटक-वृक्षों में होने वाली अचानक भारी अनुरोधों की समस्या रुकती है, जहाँ कई घटक एक ही डेटा लाते हैं।

SWR को Next.js के पीछे की कंपनी Vercel ने बनाया है और इसका एकीकरण सहज है। getServerSideProps या getStaticProps डेटा को पहले ही ला सकते हैं, और SWR क्लाइंट पर उस पहले से लाए गए मान से अपना डेटा भर लेता है।

इससे आपको सर्वर द्वारा रेंडर किया गया प्रारंभिक HTML और माउंट होने पर स्वचालित क्लाइंट-साइड पुनः सत्यापन मिलता है, यानी SSR और SWR की सबसे अच्छी खूबियों का संयोजन।

SWR पुराना डेटा देते हुए पुनः सत्यापन रणनीति लागू करता है: कैश किया हुआ डेटा तुरंत दिखाता है, पृष्ठभूमि में उसका पुनः सत्यापन करता है और नया डेटा मिलने पर इंटरफ़ेस अपडेट करता है। यह फ़ोकस आने, दोबारा कनेक्ट होने, mutate और नियमित अंतराल पर जाँच के दौरान पुनः सत्यापन शुरू करता है। वैश्विक कैश घटकों के बीच अनुरोधों को दोहरने से रोकता है और fetcher फ़ंक्शन को पूरी तरह बदला जा सकता है।

यह मॉडल डेटा लाने वाले कोड को काफ़ी सरल बनाते हुए उपयोगकर्ताओं को बेहतर अनुभव किया जाने वाला प्रदर्शन देता है।