ইনডেক্সডডিবি সহ অ্যাপ্লিকেশান স্টেট টিকে থাকার সর্বোত্তম অনুশীলন

IndexedDB এবং জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরির মধ্যে অ্যাপ্লিকেশান স্টেট সিঙ্ক করার জন্য সর্বোত্তম অনুশীলন শিখুন।

Philip Walton

যখন একজন ব্যবহারকারী প্রথম কোনো ওয়েবসাইট বা অ্যাপ্লিকেশন লোড করে, তখন প্রায়শই UI রেন্ডার করার জন্য ব্যবহৃত প্রাথমিক অ্যাপ্লিকেশান স্টেট তৈরিতে যথেষ্ট পরিমাণ কাজ জড়িত থাকে। উদাহরণস্বরূপ, কখনও কখনও অ্যাপটিকে ব্যবহারকারীর ক্লায়েন্ট-সাইডকে প্রমাণীকরণ করতে হবে এবং তারপরে পৃষ্ঠায় প্রদর্শনের জন্য প্রয়োজনীয় সমস্ত ডেটা থাকার আগে বেশ কয়েকটি API অনুরোধ করতে হবে।

IndexedDB- তে অ্যাপ্লিকেশনের অবস্থা সংরক্ষণ করা পুনরাবৃত্তি ভিজিটের জন্য লোডের সময় দ্রুত করার একটি দুর্দান্ত উপায় হতে পারে। অ্যাপটি তখন ব্যাকগ্রাউন্ডে যেকোন এপিআই পরিষেবার সাথে সিঙ্ক করতে পারে এবং অলসভাবে নতুন ডেটা দিয়ে UI আপডেট করতে পারে, একটি অচল থাকাকালীন- পুনঃপ্রমাণ কৌশল ব্যবহার করে।

যাইহোক, IndexedDB ব্যবহার করার সময় অনেকগুলি গুরুত্বপূর্ণ বিষয় বিবেচনা করতে হয় যা API-তে নতুন ডেভেলপারদের কাছে অবিলম্বে স্পষ্ট নাও হতে পারে। এই দস্তাবেজটি সাধারণ প্রশ্নের উত্তর দেয় এবং IndexedDB-তে প্রয়োগের অবস্থা বজায় রাখার সময় মনে রাখতে কিছু গুরুত্বপূর্ণ বিষয় নিয়ে আলোচনা করে।

আপনার অ্যাপটি অনুমানযোগ্য রাখুন

IndexedDB এর আশেপাশে অনেক জটিলতা এই সত্য থেকে উদ্ভূত হয় যে এমন অনেকগুলি কারণ রয়েছে যার উপর আপনার (ডেভেলপার) কোন নিয়ন্ত্রণ নেই। এই বিভাগটি IndexedDB এর সাথে কাজ করার সময় আপনাকে অবশ্যই মনে রাখতে হবে এমন অনেকগুলি বিষয় অন্বেষণ করে।

সঞ্চয়স্থানে লেখা ব্যর্থ হতে পারে

IndexedDB-তে লেখার সময় ত্রুটিগুলি বিভিন্ন কারণে ঘটতে পারে এবং কিছু ক্ষেত্রে এই কারণগুলি বিকাশকারী হিসাবে আপনার নিয়ন্ত্রণের বাইরে। উদাহরণস্বরূপ, কিছু ব্রাউজার ব্যক্তিগত ব্রাউজিং মোডে থাকাকালীন IndexedDB-তে লেখার অনুমতি দেয় না। এমনও সম্ভাবনা রয়েছে যে একজন ব্যবহারকারী এমন একটি ডিভাইসে আছেন যা প্রায় ডিস্কের জায়গার বাইরে, এবং ব্রাউজার আপনাকে কিছু সংরক্ষণ করতে সীমাবদ্ধ করবে।

এই কারণে, এটি অত্যন্ত গুরুত্বপূর্ণ যে আপনি সর্বদা আপনার IndexedDB কোডে সঠিক ত্রুটি পরিচালনা করুন। এর মানে এটিও সাধারণত অ্যাপ্লিকেশনের অবস্থা মেমরিতে রাখা একটি ভাল ধারণা (এটি সঞ্চয় করার পাশাপাশি), তাই ব্যক্তিগত ব্রাউজিং মোডে চলাকালীন বা স্টোরেজ স্পেস উপলব্ধ না হলে UI ভেঙে যায় না (এমনকি যদি অন্য কিছু স্টোরেজ প্রয়োজন এমন অ্যাপ বৈশিষ্ট্য কাজ করবে না)।

সংরক্ষিত তথ্য ব্যবহারকারী দ্বারা সংশোধন বা মুছে ফেলা হতে পারে

সার্ভার-সাইড ডাটাবেসগুলির বিপরীতে যেখানে আপনি অননুমোদিত অ্যাক্সেস সীমাবদ্ধ করতে পারেন, ক্লায়েন্ট-সাইড ডেটাবেসগুলি ব্রাউজার এক্সটেনশন এবং বিকাশকারী সরঞ্জামগুলিতে অ্যাক্সেসযোগ্য এবং সেগুলি ব্যবহারকারী দ্বারা সাফ করা যেতে পারে।

যদিও ব্যবহারকারীদের জন্য তাদের স্থানীয়ভাবে সঞ্চিত ডেটা পরিবর্তন করা অস্বাভাবিক হতে পারে, ব্যবহারকারীদের পক্ষে এটি পরিষ্কার করা বেশ সাধারণ। এটি গুরুত্বপূর্ণ যে আপনার অ্যাপ্লিকেশন ত্রুটি ছাড়াই এই উভয় ক্ষেত্রেই পরিচালনা করতে পারে৷

সংরক্ষিত তথ্য পুরানো হতে পারে

পূর্ববর্তী বিভাগের অনুরূপ, এমনকি যদি ব্যবহারকারী নিজেরাই ডেটা পরিবর্তন না করে থাকেন, তবে এটাও সম্ভব যে তাদের স্টোরেজে থাকা ডেটা আপনার কোডের পূর্ববর্তী সংস্করণ দ্বারা লেখা হয়েছে, সম্ভবত এটিতে বাগ সহ একটি সংস্করণ।

IndexedDB এর IDBOpenDBRequest.onupgradeneeded() পদ্ধতি ব্যবহার করে স্কিমা সংস্করণ এবং আপগ্রেড করার জন্য অন্তর্নির্মিত সমর্থন রয়েছে; যাইহোক, আপনাকে এখনও আপনার আপগ্রেড কোডটি এমনভাবে লিখতে হবে যাতে এটি পূর্ববর্তী সংস্করণ থেকে আসা ব্যবহারকারীকে পরিচালনা করতে পারে (একটি বাগ সহ সংস্করণ সহ)।

ইউনিট পরীক্ষাগুলি এখানে খুব সহায়ক হতে পারে, কারণ সমস্ত সম্ভাব্য আপগ্রেড পাথ এবং ক্ষেত্রে ম্যানুয়ালি পরীক্ষা করা প্রায়শই সম্ভব হয় না।

আপনার অ্যাপ্লিকেশন পারফরম্যান্স রাখুন

IndexedDB এর মূল বৈশিষ্ট্যগুলির মধ্যে একটি হল এটির অ্যাসিঙ্ক্রোনাস API, কিন্তু এটি ব্যবহার করার সময় পারফরম্যান্স নিয়ে আপনার চিন্তা করার দরকার নেই এমন চিন্তায় আপনাকে বোকা বানাতে দেবেন না। এমন অনেকগুলি ক্ষেত্রে রয়েছে যেখানে অনুপযুক্ত ব্যবহার এখনও মূল থ্রেডটিকে ব্লক করতে পারে, যা প্রতিক্রিয়াহীনতার দিকে পরিচালিত করতে পারে।

একটি সাধারণ নিয়ম হিসাবে, ইনডেক্সডডিবিতে পড়া এবং লেখা ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয়তার চেয়ে বড় হওয়া উচিত নয়।

যদিও IndexedDB বড়, নেস্টেড বস্তুগুলিকে একক রেকর্ড হিসাবে সংরক্ষণ করা সম্ভব করে (এবং এটি করা একটি বিকাশকারীর দৃষ্টিকোণ থেকে স্বীকৃতভাবে বেশ সুবিধাজনক), এই অভ্যাসটি এড়ানো উচিত। কারণ হল যখন IndexedDB একটি অবজেক্ট সঞ্চয় করে, এটিকে প্রথমে সেই বস্তুর একটি স্ট্রাকচার্ড ক্লোন তৈরি করতে হবে এবং কাঠামোগত ক্লোনিং প্রক্রিয়াটি প্রধান থ্রেডে ঘটে। বস্তুটি যত বড় হবে, ব্লক করার সময় তত বেশি হবে।

IndexedDB-তে অ্যাপ্লিকেশন স্টেট কীভাবে বজায় রাখা যায় তা পরিকল্পনা করার সময় এটি কিছু চ্যালেঞ্জ উপস্থাপন করে, কারণ বেশিরভাগ জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরি (যেমন Redux ) আপনার সম্পূর্ণ স্টেট ট্রিকে একটি একক জাভাস্ক্রিপ্ট অবজেক্ট হিসাবে পরিচালনা করে কাজ করে।

এইভাবে রাজ্য পরিচালনার অনেক সুবিধা রয়েছে, এবং ইনডেক্সডডিবি-তে একটি একক রেকর্ড হিসাবে সমগ্র রাজ্য গাছ সংরক্ষণ করার সময় লোভনীয় এবং সুবিধাজনক হতে পারে, প্রতিটি পরিবর্তনের পরে (এমনকি থ্রোটল/ডিবাউন্স করা হলেও) এটি করার ফলে প্রধানটির জন্য অপ্রয়োজনীয় ব্লক করা হবে। থ্রেড, এটি লেখার ত্রুটির সম্ভাবনা বাড়িয়ে তুলবে এবং কিছু ক্ষেত্রে এটি ব্রাউজার ট্যাবকে ক্র্যাশ বা প্রতিক্রিয়াহীন হওয়ার কারণও হতে পারে।

একটি একক রেকর্ডে সমগ্র রাজ্য গাছ সঞ্চয় করার পরিবর্তে, আপনার এটিকে পৃথক রেকর্ডে বিভক্ত করা উচিত এবং শুধুমাত্র সেই রেকর্ডগুলি আপডেট করা উচিত যা প্রকৃতপক্ষে পরিবর্তিত হয়৷

বেশিরভাগ সেরা অনুশীলনের মতো, এটি একটি সব-বা-কিছুই নিয়ম নয়। যে ক্ষেত্রে কোনো স্টেট অবজেক্ট ভাঙ্গা সম্ভব নয় এবং শুধুমাত্র ন্যূনতম পরিবর্তন-সেট লিখুন, ডেটাকে উপ-বৃক্ষে বিভক্ত করা এবং শুধুমাত্র সেগুলি লেখা সর্বদা সমগ্র রাষ্ট্রীয় গাছ লেখার চেয়ে পছন্দনীয়। সামান্য উন্নতি মোটেও কোন উন্নতির চেয়ে ভাল।

সবশেষে, আপনার লেখা কোডের কার্যক্ষমতার প্রভাব সবসময় পরিমাপ করা উচিত। যদিও এটি সত্য যে IndexedDB-তে ছোট লেখাগুলি বড় লেখার চেয়ে ভাল কাজ করবে, তবে এটি শুধুমাত্র গুরুত্বপূর্ণ যদি IndexedDB-কে লিখতে হয় যে আপনার অ্যাপ্লিকেশনটি আসলে দীর্ঘ কাজগুলির দিকে পরিচালিত করে যা মূল থ্রেডকে ব্লক করে এবং ব্যবহারকারীর অভিজ্ঞতাকে হ্রাস করে। এটি পরিমাপ করা গুরুত্বপূর্ণ যাতে আপনি বুঝতে পারেন যে আপনি কিসের জন্য অপ্টিমাইজ করছেন৷

উপসংহার

বিকাশকারীরা তাদের অ্যাপ্লিকেশনের ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে IndexedDB-এর মতো ক্লায়েন্ট স্টোরেজ মেকানিজম ব্যবহার করতে পারে শুধুমাত্র সেশন জুড়ে স্থিতি বজায় রেখেই নয়, বারবার ভিজিট করার সময় প্রাথমিক অবস্থা লোড করতে সময় কমিয়েও।

সঠিকভাবে IndexedDB ব্যবহার করলে ব্যবহারকারীর অভিজ্ঞতা নাটকীয়ভাবে উন্নত হতে পারে, এটিকে ভুলভাবে ব্যবহার করা বা ত্রুটির ঘটনাগুলি পরিচালনা করতে ব্যর্থ হলে তা ভাঙা অ্যাপ এবং অসুখী ব্যবহারকারীদের দিকে নিয়ে যেতে পারে।

যেহেতু ক্লায়েন্ট সঞ্চয়স্থানে আপনার নিয়ন্ত্রণের বাইরে অনেক বিষয় জড়িত থাকে, তাই এটি গুরুত্বপূর্ণ যে আপনার কোডটি ভালভাবে পরীক্ষা করা হয়েছে এবং সঠিকভাবে ত্রুটিগুলি পরিচালনা করে, এমনকি যেগুলি প্রাথমিকভাবে ঘটার সম্ভাবনা কম বলে মনে হতে পারে।