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 का सही तरीके से इस्तेमाल करने पर, उपयोगकर्ता अनुभव को काफ़ी बेहतर बनाया जा सकता है. हालांकि, इसका गलत तरीके से इस्तेमाल करने या गड़बड़ी के मामलों को ठीक न कर पाने से, ऐप्लिकेशन काम करना बंद कर सकते हैं और उपयोगकर्ताओं को खराब अनुभव मिल सकता है.
क्लाइंट स्टोरेज में कई ऐसे फ़ैक्टर शामिल होते हैं जो आपके कंट्रोल से बाहर होते हैं. इसलिए, यह ज़रूरी है कि आपके कोड की अच्छी तरह से जांच की गई हो और वह गड़बड़ियों को ठीक से हैंडल करता हो. भले ही, वे गड़बड़ियां ऐसी हों जो शुरुआत में होने की संभावना न हो.