IndexedDB का इस्तेमाल करने के सबसे सही तरीके

IndexedDB एक लोकप्रिय स्टेट मैनेजमेंट लाइब्रेरी के बीच ऐप्लिकेशन की स्थिति को सिंक करने के सबसे सही तरीके जानें.

Philip Walton

जब कोई उपयोगकर्ता पहली बार किसी वेबसाइट या ऐप्लिकेशन को लोड करता है, तब अक्सर काफ़ी काम की यूज़र इंटरफ़ेस (यूआई) को रेंडर करने के लिए इस्तेमाल की जाने वाली शुरुआती ऐप्लिकेशन स्थिति बनाना. उदाहरण के लिए, कभी-कभी ऐप्लिकेशन को उपयोगकर्ता क्लाइंट-साइड की पुष्टि करने की ज़रूरत होगी. इसके बाद, एपीआई अनुरोध भेजने से पहले, उपयोगकर्ता को कई एपीआई अनुरोध करने होंगे वह डेटा जिसे पेज पर दिखाना है.

ऐप्लिकेशन की स्थिति को इसमें सेव किया जा रहा है IndexedDB, वेबसाइट की स्पीड को तेज़ी से बढ़ाने का एक शानदार तरीका है वेबसाइट पर बार-बार आने वाले लोगों की संख्या लोड होने में लगने वाला समय. इसके बाद ऐप्लिकेशन, बैकग्राउंड में मौजूद किसी भी एपीआई सेवा के साथ सिंक कर सकता है और आसानी से नए डेटा के साथ यूज़र इंटरफ़ेस (यूआई) को अपडेट करें. stale-while- reverify की रणनीति का इस्तेमाल करना.

IndexedDB के लिए एक और अच्छा इस्तेमाल, यूज़र जनरेटेड कॉन्टेंट को स्टोर करना है, या तो इसे अस्थायी स्टोर के तौर पर भी स्टोर किया जा सकता है इससे पहले कि उसे सर्वर पर अपलोड किया जाए या रिमोट डेटा के क्लाइंट-साइड कैश के तौर पर अपलोड किया जाए - या, बेशक, दोनों.

हालांकि, IndexedDB का इस्तेमाल करते समय ऐसी कई अहम चीज़ों पर विचार करना ज़रूरी है जो शायद इस एपीआई का इस्तेमाल शुरू करने वाले नए डेवलपर को यह तुरंत लागू हो जाएगी. इस लेख में, आम तौर पर पूछे जाने वाले सवालों के जवाब हैं और यह IndexedDB में डेटा बनाए रखते समय ध्यान रखने वाली कुछ सबसे अहम चीज़ों पर चर्चा करता है.

अपने ऐप्लिकेशन के लिए अनुमान लगाना आसान बनाएं

IndexedDB से जुड़ी कई समस्याएं इस बात से जुड़ी हैं कि आपके पास ऐसी कई वजहें हैं (डेवलपर) का कोई कंट्रोल नहीं होता है. इस सेक्शन में ऐसी कई समस्याओं के बारे में बताया गया है जिनका आपको ध्यान रखना चाहिए जब IndexedDB के साथ काम करना हो.

सभी प्लैटफ़ॉर्म पर IndexedDB में सब कुछ सेव नहीं किया जा सकता

अगर इमेज या वीडियो जैसी उपयोगकर्ता की जनरेट की गई बड़ी फ़ाइलें सेव की जा रही हैं, तो उन्हें सेव करने की कोशिश करें उन्हें File या Blob ऑब्जेक्ट के तौर पर सबमिट करते हैं. यह कुछ प्लैटफ़ॉर्म पर काम करेगा, लेकिन अन्य प्लैटफ़ॉर्म पर काम नहीं करेगा. Safari चालू है खास तौर पर, iOS Blobs को IndexedDB में सेव नहीं कर सकता.

अच्छी बात यह है कि किसी Blob को ArrayBuffer में बदलना बहुत मुश्किल नहीं है और इसके उलट भी. स्टोर करना IndexedDB में ArrayBuffer बहुत अच्छी तरह से काम करता है.

हालांकि, याद रखें कि Blob में MIME टाइप होता है, जबकि ArrayBuffer में नहीं. आपको इन चीज़ों की ज़रूरत होगी सही तरीके से कन्वर्ज़न करने के लिए, टाइप को बफ़र के साथ सेव करें.

ArrayBuffer को Blob में बदलने के लिए, आपको सिर्फ़ Blob कंस्ट्रक्टर का इस्तेमाल करना होगा.

function arrayBufferToBlob(buffer, type) {
  return new Blob([buffer], { type: type });
}

दूसरी दिशा थोड़ी ज़्यादा शामिल है और यह एक एसिंक्रोनस प्रोसेस है. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए BLOB को ArrayBuffer के तौर पर पढ़ने के लिए, FileReader ऑब्जेक्ट है. रीडिंग पूरी होने पर loadend इवेंट रीडर पर ट्रिगर होता है. इस प्रोसेस को Promise में इस तरह पूरा किया जा सकता है:

function blobToArrayBuffer(blob) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.addEventListener('loadend', () => {
      resolve(reader.result);
    });
    reader.addEventListener('error', reject);
    reader.readAsArrayBuffer(blob);
  });
}

डिवाइस के स्टोरेज में सेव नहीं किया जा सकता

IndexedDB पर लिखते समय गड़बड़ी कई वजहों से हो सकती है और कुछ मामलों में ये में, डेवलपर के तौर पर आपका कंट्रोल नहीं है. उदाहरण के लिए, वर्तमान में कुछ ब्राउज़र निजी ब्राउज़िंग मोड में होने पर, IndexedDB पर लिखना. ऐसा भी हो सकता है कि उपयोगकर्ता किसी ऐसे डिवाइस पर हो जिसके डिस्क में स्टोरेज खत्म होने वाला हो और ब्राउज़र आपको कुछ भी संग्रहित करने से प्रतिबंधित कर देगा.

इस वजह से यह ज़रूरी है कि आप हमेशा अपने डिवाइस में गड़बड़ियों को ठीक करने के तरीके लागू करें IndexedDB कोड. इसका यह भी अर्थ है कि एप्लिकेशन स्थिति को मेमोरी में ( साथ ही, स्टोर करने के अलावा कोई और विकल्प भी मिलता है, ताकि निजी ब्राउज़िंग मोड में इस्तेमाल करते समय या जब डिवाइस में स्टोरेज के लिए जगह उपलब्ध नहीं है (भले ही, ऐप्लिकेशन की कुछ ऐसी सुविधाएं उपलब्ध हों जिनके लिए स्टोरेज की ज़रूरत होती है) काम).

error इवेंट के लिए इवेंट हैंडलर जोड़कर, IndexedDB की कार्रवाइयों में गड़बड़ियां पकड़ी जा सकती हैं जब भी आप IDBDatabase, IDBTransaction या IDBRequest ऑब्जेक्ट बनाते हैं.

const request = db.open('example-db', 1);
request.addEventListener('error', (event) => {
  console.log('Request error:', request.error);
};

ऐसा हो सकता है कि उपयोगकर्ता ने सेव किए गए डेटा में बदलाव किया हो या उसे मिटा दिया हो

वहीं, सर्वर साइड डेटाबेस में बिना अनुमति के ऐक्सेस पर रोक लगाने का विकल्प होता है. वहीं, क्लाइंट-साइड डेटाबेस को और उन्हें उपयोगकर्ता एक्सटेंशन और डेवलपर टूल से ऐक्सेस कर सकता है और उन्हें हटा सकता है.

ऐसा हो सकता है कि डिवाइस पर सेव किए गए डेटा में, उपयोगकर्ता कुछ खास बदलाव न करें. हालांकि, यह आम बात है उसे हटाने के लिए. यह ज़रूरी है कि आपका ऐप्लिकेशन बिना किसी गड़बड़ी के इन दोनों मामलों को हैंडल कर सके.

सेव किया गया डेटा पुराना हो सकता है

पिछले सेक्शन की तरह ही, भले ही उपयोगकर्ता ने खुद डेटा में कोई बदलाव न किया हो, लेकिन यह हो सकता है कि उसके स्टोरेज में मौजूद डेटा आपके कोड के किसी पुराने वर्शन से लिखा गया हो. जिसमें बग हैं.

IndexedDB में स्कीमा वर्शन के लिए पहले से ही सहायता मौजूद है और उसे इसके ज़रिए अपग्रेड किया जा सकता है IDBOpenDBRequest.onupgradeneeded() तरीका; हालांकि, आपको अब भी अपना अपग्रेड कोड इस तरह लिखना होगा कि वह उपयोगकर्ता को पिछले वर्शन से आ रहा है (इसमें गड़बड़ी वाला वर्शन भी शामिल है).

यूनिट टेस्ट यहां बहुत मददगार हो सकते हैं, क्योंकि हर संभव तरीके को मैन्युअल तौर पर टेस्ट नहीं किया जा सकता अपग्रेड के पाथ और केस की जानकारी मौजूद होनी चाहिए.

अपने ऐप्लिकेशन की परफ़ॉर्मेंस बेहतर बनाए रखना

IndexedDB की सबसे अहम सुविधाओं में से एक इसका एसिंक्रोनस एपीआई है. हालांकि, इसके बारे में आपको किसी भी तरह की ग़लतफ़हमी न करें यह सोच रहे हैं कि आपको उसका उपयोग करते समय प्रदर्शन के बारे में चिंता करने की आवश्यकता नहीं है. ऐसे कई मामले हैं जिनमें गलत तरीके से इस्तेमाल करने पर भी मुख्य थ्रेड ब्लॉक हो सकता है. इसकी वजह से जैंक होने लगता है और काम न करने की समस्या आ सकती है.

एक सामान्य नियम के तौर पर, IndexedDB पर पढ़ने और लिखने का तरीका, डेटा के लिए ज़रूरी से बड़ा नहीं होना चाहिए ऐक्सेस नहीं किया जा सकता.

हालांकि, IndexedDB पर नेस्ट किए गए बड़े ऑब्जेक्ट को एक ही रिकॉर्ड के तौर पर सेव करने की सुविधा मिलती है. ऐसा करने पर डेवलपर के नज़रिए से देखा जाए, तो इस तरीके से बचना चाहिए. कॉन्टेंट बनाने इसकी वजह यह है कि जब IndexedDB किसी ऑब्जेक्ट को स्टोर करता है, तो पहले उसे स्ट्रक्चर्ड क्लोन ऑब्जेक्ट को हटा दिया जाता है और स्ट्रक्चर्ड क्लोनिंग प्रोसेस मुख्य थ्रेड पर होती है. वैल्यू जितनी बड़ी होगी ऑब्जेक्ट को ब्लॉक करने का समय उतना ही ज़्यादा होगा.

इस वजह से, IndexedDB पर ऐप्लिकेशन की स्थिति को बनाए रखने की योजना बनाने के दौरान कुछ चुनौतियां आती हैं. आम तौर पर, लोकप्रिय स्टेट मैनेजमेंट लाइब्रेरी (जैसे, Redux) का काम पूरे स्टेट ट्री को एक JavaScript ऑब्जेक्ट के तौर पर शामिल करता है.

इस तरह से स्टेटस मैनेज करने के कई फ़ायदे हैं. उदाहरण के लिए, इससे कोड को मैनेज करना आसान हो जाता है और डीबग), जबकि पूरे स्टेट ट्री को बस IndexedDB में एक रिकॉर्ड के रूप में संग्रहित करना हो सकता है यह आकर्षक और सुविधाजनक होता है. ऐसा हर बदलाव के बाद (भले ही थ्रॉटल किया गया हो या न किया गया हो) करने का नतीजा मिलेगा मुख्य थ्रेड को बेवजह ब्लॉक नहीं किया जाएगा. इससे लिखने में गड़बड़ी होने की संभावना बढ़ जाएगी. साथ ही, कुछ मामलों में इसकी वजह से ब्राउज़र टैब क्रैश हो जाता है या काम करना बंद कर देता है.

पूरे स्टेट ट्री को एक रिकॉर्ड में सेव करने के बजाय, आपको इसे अलग-अलग हिस्सों में बांटना चाहिए रिकॉर्ड करती है और सिर्फ़ उन रिकॉर्ड को अपडेट करती है जो असल में बदलते हैं.

जब आप IndexedDB में इमेज, संगीत या वीडियो जैसे बड़े आइटम स्टोर करते हैं, तब भी ऐसा ही होता है. हर आइटम को सेव करें के बजाय अपनी कुंजी का इस्तेमाल किया जा सकता है, ताकि आप स्ट्रक्चर्ड डेटा वापस पा सकें और बाइनरी फ़ाइल को फिर से पाने की लागत पर भी पैसे खर्च किए बिना.

ज़्यादातर सबसे सही तरीकों की तरह, यह भी 'कुछ नहीं' नियम है. उन मामलों में जहां यह संभव नहीं है स्टेट ऑब्जेक्ट को अलग-अलग करें और डेटा को सब-ट्री में बांटते हुए, कम से कम बदलाव वाला सेट लिखें और हमेशा उन्हें लिखना ही बेहतर होता है, जबकि पूरे स्टेट ट्री को हमेशा लिखा जाना चाहिए. लिटिल सुधार न होने से बेहतर हैं.

आखिर में, आपको हमेशा परफ़ॉर्मेंस के असर का आकलन करना चाहिए कोड होता है. हालांकि, यह सच है कि IndexedDB पर छोटे लिखने पर, वे बड़े फ़ंक्शन से बेहतर परफ़ॉर्म करेंगे लिखता है, यह केवल तभी महत्वपूर्ण है जब IndexedDB को लिखा जाना चाहिए कि आपका ऐप्लिकेशन वास्तव में ले जा रहा है लंबे टास्क जो मुख्य थ्रेड को ब्लॉक करती हैं और उपयोगकर्ता अनुभव को कम करती हैं. यह आकलन करना ज़रूरी है कि समझें कि आपको किस चीज़ के लिए ऑप्टिमाइज़ करना है.

मीटिंग में सामने आए नतीजे

डेवलपर, IndexedDB जैसे क्लाइंट स्टोरेज तरीकों का इस्तेमाल करके उनका इस्तेमाल, न सिर्फ़ सभी सेशन में लागू होने के साथ-साथ उसके समय को कम करके वेबसाइट पर बार-बार आने वाले लोगों की शुरुआती स्थिति लोड होती है.

हालांकि, IndexedDB का सही तरीके से इस्तेमाल करने पर उपयोगकर्ता अनुभव में काफ़ी सुधार हो सकता है, लेकिन उसका गलत तरीके से इस्तेमाल करना या गड़बड़ी के मामलों को हैंडल न कर पाने पर, काम न करने वाले ऐप्लिकेशन दिख सकते हैं और उपयोगकर्ता नाखुश हो सकते हैं.

क्लाइंट स्टोरेज में ऐसे कई फ़ैक्टर शामिल हैं जो आपके कंट्रोल से बाहर हैं, इसलिए यह ज़रूरी है कि आपका कोड सही हो गड़बड़ियों की जांच कर लेता है और उन्हें सही तरीके से हैंडल करता है, भले ही उन गड़बड़ियों के होने की संभावना न के बराबर हो.