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