IndexedDB और स्टेटस मैनेजमेंट की लोकप्रिय लाइब्रेरी के बीच, ऐप्लिकेशन की स्थिति को सिंक करने के सबसे सही तरीके जानें.
जब कोई उपयोगकर्ता पहली बार किसी वेबसाइट या ऐप्लिकेशन को लोड करता है, तो यूज़र इंटरफ़ेस (यूआई) रेंडर करने के लिए, शुरुआती ऐप्लिकेशन स्थिति को बनाने में अक्सर काफ़ी काम करना पड़ता है. उदाहरण के लिए, कभी-कभी ऐप्लिकेशन को उपयोगकर्ता के क्लाइंट-साइड की पुष्टि करनी पड़ती है. इसके बाद, पेज पर दिखाने के लिए ज़रूरी डेटा मिलने से पहले, उसे कई एपीआई अनुरोध करने पड़ते हैं.
IndexedDB में ऐप्लिकेशन की स्थिति सेव करने से, दोबारा विज़िट करने पर लोड होने में लगने वाला समय कम हो सकता है. इसके बाद, ऐप्लिकेशन बैकग्राउंड में किसी भी एपीआई सेवा के साथ सिंक हो सकता है और stale-while- revalidate रणनीति का इस्तेमाल करके, यूज़र इंटरफ़ेस को नए डेटा के साथ अपडेट कर सकता है.
हालांकि, IndexedDB का इस्तेमाल करते समय कई अहम बातों का ध्यान रखना ज़रूरी है. ये बातें, एपीआई का इस्तेमाल करने वाले नए डेवलपर को तुरंत समझ नहीं आ सकतीं. इस दस्तावेज़ में सामान्य सवालों के जवाब दिए गए हैं. साथ ही, IndexedDB में ऐप्लिकेशन की स्थिति को बनाए रखते समय, ध्यान में रखी जाने वाली कुछ अहम बातों पर चर्चा की गई है.
अपने ऐप्लिकेशन के बारे में अनुमान लगाने की सुविधा चालू रखें
IndexedDB से जुड़ी कई समस्याएं इस बात से जुड़ी हैं कि इसमें कई ऐसे फ़ैक्टर होते हैं जिन पर आपके (डेवलपर) का कंट्रोल नहीं होता. इस सेक्शन में ऐसी कई समस्याओं के बारे में बताया गया है जिनका आपको IndexedDB के साथ काम करते समय ध्यान रखना चाहिए.
डिवाइस के स्टोरेज में सेव नहीं किया जा सकता
IndexedDB में डेटा लिखते समय कई वजहों से गड़बड़ियां हो सकती हैं. साथ ही, कुछ मामलों में डेवलपर के तौर पर इन वजहों को कंट्रोल नहीं किया जा सकता. उदाहरण के लिए, कुछ ब्राउज़र निजी ब्राउज़िंग मोड में IndexedDB में डेटा सेव करने की अनुमति नहीं देते. ऐसा भी हो सकता है कि उपयोगकर्ता किसी ऐसे डिवाइस का इस्तेमाल कर रहा हो जिसके डिस्क में स्टोरेज खत्म होने वाला है और ब्राउज़र आपको कुछ भी सेव करने से रोक देगा.
इस वजह से यह ज़रूरी हो जाता है कि आप हमेशा अपने IndexedDB कोड में गड़बड़ी को सही तरीके से मैनेज करें. इसका मतलब यह भी है कि ऐप्लिकेशन की स्थिति को मेमोरी में बनाए रखना एक अच्छा आइडिया है (इसे स्टोर करने के अलावा), इसलिए निजी ब्राउज़िंग मोड में चलने या स्टोरेज उपलब्ध न होने पर भी यूज़र इंटरफ़ेस (यूआई) काम नहीं करता (भले ही ऐप्लिकेशन की ऐसी कुछ सुविधाएं काम न करें जिन्हें स्टोरेज की ज़रूरत होती है).
ऐसा हो सकता है कि उपयोगकर्ता ने सेव किए गए डेटा में बदलाव किया हो या उसे मिटा दिया हो
सर्वर साइड डेटाबेस जहां बिना अनुमति के ऐक्सेस पर रोक लगाई जा सकती है उसके उलट, क्लाइंट-साइड डेटाबेस को ब्राउज़र एक्सटेंशन और डेवलपर टूल से ऐक्सेस किया जा सकता है और उपयोगकर्ता इन्हें मिटा सकता है.
उपयोगकर्ता, स्थानीय तौर पर सेव किए गए डेटा में आम तौर पर बदलाव नहीं करते. हालांकि, वे उसे मिटा देते हैं. यह ज़रूरी है कि आपका ऐप्लिकेशन, गड़बड़ी के बिना इन दोनों मामलों को मैनेज कर सके.
सेव किया गया डेटा पुराना हो सकता है
पिछले सेक्शन की तरह ही, भले ही उपयोगकर्ता ने डेटा में खुद बदलाव न किया हो, लेकिन यह भी हो सकता है कि उसके स्टोरेज में मौजूद डेटा को आपके कोड के किसी पुराने वर्शन ने लिखा हो. हो सकता है कि उस वर्शन में गड़बड़ियां हों.
IndexedDB में स्कीमा वर्शन के लिए सहायता पहले से मौजूद है और यह उसके IDBOpenDBRequest.onupgradeneeded() तरीके का इस्तेमाल करके अपग्रेड करने की सुविधा देता है. हालांकि, आपको अब भी अपने अपग्रेड कोड को इस तरह से लिखना होगा कि वह पिछले वर्शन से आने वाले उपयोगकर्ता को मैनेज कर सके (इसमें गड़बड़ी वाला वर्शन भी शामिल है).
यूनिट टेस्ट यहां बहुत मददगार हो सकते हैं, क्योंकि अक्सर सभी संभावित अपग्रेड पाथ और केस की मैन्युअल तौर पर जांच करना संभव नहीं होता.
अपने ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाए रखना
IndexedDB की सबसे अहम सुविधाओं में से एक इसका एसिंक्रोनस एपीआई है. हालांकि, इस बात का ध्यान रखें कि इससे आपको यह सोचने पर मजबूर न करें कि आपको इसका इस्तेमाल करते समय परफ़ॉर्मेंस को लेकर परेशान होने की ज़रूरत नहीं है. कई मामलों में, गलत इस्तेमाल की वजह से मुख्य थ्रेड ब्लॉक हो सकता है. इससे, हो सकता है कि आपका ऐप्लिकेशन काम न करे.
आम तौर पर, IndexedDB में डेटा को पढ़ने और उसमें डेटा सेव करने की प्रोसेस, ऐक्सेस किए जा रहे डेटा के लिए ज़रूरी से ज़्यादा नहीं होनी चाहिए.
IndexedDB की मदद से, बड़े और नेस्ट किए गए ऑब्जेक्ट को एक ही रिकॉर्ड के तौर पर सेव किया जा सकता है. हालांकि, डेवलपर के लिहाज़ से ऐसा करना काफ़ी आसान है, लेकिन इस तरीके का इस्तेमाल नहीं किया जाना चाहिए. इसकी वजह यह है कि जब IndexedDB किसी ऑब्जेक्ट को सेव करता है, तो पहले उसे उस ऑब्जेक्ट का स्ट्रक्चर्ड क्लोन बनाना चाहिए. साथ ही, स्ट्रक्चर्ड क्लोनिंग की प्रोसेस मुख्य थ्रेड पर होती है. ऑब्जेक्ट जितना बड़ा होगा, ब्लॉक करने में उतना ही ज़्यादा समय लगेगा.
ऐप्लिकेशन की स्थिति को IndexedDB में बनाए रखने की योजना बनाते समय, इसके सामने कुछ चुनौतियां आती हैं. इसकी वजह यह है कि ज़्यादातर लोकप्रिय स्टेट मैनेजमेंट लाइब्रेरी (जैसे कि Redux) आपके पूरे स्टेट ट्री को एक सिंगल JavaScript ऑब्जेक्ट के तौर पर मैनेज करके काम करती हैं.
इस तरीके से स्टेट मैनेज करने के कई फ़ायदे होते हैं, वहीं, IndexedDB में पूरे स्टेट ट्री को एक ही रिकॉर्ड के रूप में सेव करने से दिलचस्प और आसान हो सकता है, लेकिन हर बदलाव के बाद (भले ही थ्रॉटल/डिबॉउंस किया गया हो) ऐसा करना, मुख्य थ्रेड के लिए बेवजह ब्लॉक करने की वजह बनेगा. इससे, लिखने से जुड़ी गड़बड़ियां होने की संभावना बढ़ जाएगी. साथ ही, कुछ मामलों में इससे ब्राउज़र टैब क्रैश या क्रैश होने की संभावना भी बढ़ जाएगी.
पूरे स्टेट ट्री को एक ही रिकॉर्ड में सेव करने के बजाय, आपको उसे अलग-अलग रिकॉर्ड में बांटना चाहिए. साथ ही, सिर्फ़ उन रिकॉर्ड को अपडेट करना चाहिए जिनमें बदलाव हुआ है.
सबसे सही तरीकों की तरह, यह भी 'कुछ नहीं' नियम है. ऐसे मामलों में जहां राज्य की किसी चीज़ को तोड़ना और बस मिनिमम चेंज-सेट लिखना मुमकिन न हो वहां डेटा को सब-ट्री में बांटते हुए सिर्फ़ उन्हें लिखना बेहतर होता है. इसके लिए, हमेशा पूरे स्टेट ट्री को लिखना बेहतर होगा. थोड़े सुधार करना, बिल्कुल सुधार न करने से बेहतर है.
आखिर में, आपको हमेशा लिखे गए कोड के परफ़ॉर्मेंस के असर का आकलन करना चाहिए. हालांकि, यह सच है कि IndexedDB पर छोटे लिखने से बेहतर परफ़ॉर्म होगा, लेकिन यह सिर्फ़ तब ज़रूरी है, जब IndexedDB को लिखा जाए कि आपका ऐप्लिकेशन असल में ऐसे लंबे टास्क पर ले जा रहा हो जो मुख्य थ्रेड को ब्लॉक करते हैं और उपयोगकर्ता अनुभव को कम करते हैं. यह आकलन करना ज़रूरी है, ताकि आप समझ सकें कि आप किस चीज़ के लिए ऑप्टिमाइज़ कर रहे हैं.
मीटिंग में सामने आए नतीजे
डेवलपर अपने ऐप्लिकेशन के उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, IndexedDB जैसे क्लाइंट स्टोरेज तरीकों का इस्तेमाल कर सकते हैं. ऐसा करने के लिए, न सिर्फ़ पूरे सेशन में उनकी मौजूदा स्थिति बनी रहेगी, बल्कि बार-बार होने वाली विज़िट पर शुरुआती स्थिति लोड होने में लगने वाले समय को भी कम किया जा सकता है.
हालांकि, IndexedDB का सही तरीके से इस्तेमाल करने से उपयोगकर्ता अनुभव काफ़ी बेहतर हो सकता है, लेकिन इसका गलत तरीके से इस्तेमाल करने या गड़बड़ी के मामलों को हैंडल न कर पाने की वजह से, ऐप्लिकेशन काम करना बंद कर सकते हैं और उपयोगकर्ता खुश नहीं हो सकते.
क्लाइंट स्टोरेज में ऐसे कई फ़ैक्टर शामिल हैं जो आपके कंट्रोल से बाहर हैं. इसलिए, यह ज़रूरी है कि आपके कोड की अच्छी तरह से जांच की गई है और यह गड़बड़ियों को ठीक से हैंडल करता है. भले ही, ऐसा हो सकता है कि शुरू में होने वाली गड़बड़ियां भी न हों.