با روال‌های مطلوب برای همگام‌سازی وضعیت برنامه بین IndexedDB و کتابخانه‌های مدیریت وضعیت محبوب آشنا شوید.
وقتی کاربر برای اولین‌بار وب‌سایت یا برنامه‌ای را بار می‌کند، اغلب مقدار قابل‌توجهی کار برای ساختن وضعیت اولیه برنامه که برای ارائه رابط کاربری استفاده می‌شود وجود دارد. برای مثال، گاهی اوقات برنامه باید کاربر را در سمت کارخواه اصالت‌سنجی کند و سپس چندین درخواست API ارسال کند تا بتواند همه داده‌های موردنیاز برای نمایش در صفحه را دریافت کند.
ذخیره کردن وضعیت برنامه در IndexedDB می‌تواند روشی عالی برای افزایش سرعت زمان بارگیری برای بازدیدهای تکراری باشد. سپس برنامه می‌تواند با هر سرویس API در پس‌زمینه همگام‌سازی شود و بااستفاده از استراتژی stale-while- revalidate، واسط کاربر را با داده‌های جدید به‌روز کند.
بااین‌حال، هنگام استفاده از IndexedDB، موارد مهم زیادی وجود دارد که باید درنظر گرفته شود که ممکن است برای توسعه‌دهندگانی که با APIها آشنا نیستند، فوراً آشکار نباشد. این سند به سؤالات متداول پاسخ می‌دهد و برخی‌از مهم‌ترین نکاتی را که باید هنگام حفظ وضعیت برنامه در IndexedDB درنظر داشته باشید، مورد بحث قرار می‌دهد.
برنامه‌تان را پیش‌بینی‌شدنی نگه دارید
بسیاری از پیچیدگی‌های IndexedDB ناشی از این واقعیت است که عوامل زیادی وجود دارد که شما (توسعه‌دهنده) هیچ کنترلی بر آن‌ها ندارید. این بخش به بررسی بسیاری از مسائلی می‌پردازد که باید هنگام کار با IndexedDB درنظر داشته باشید.
ممکن است نوشتن در فضای ذخیره‌سازی انجام نشود
خطاها هنگام نوشتن در IndexedDB ممکن است به‌دلایل مختلفی رخ دهد و در برخی موارد این دلایل خارج از کنترل شما به‌عنوان توسعه‌دهنده است. برای مثال، برخی‌از مرورگرها نوشتن در IndexedDB را هنگام استفاده از حالت مرور خصوصی مجاز نمی‌دانند. همچنین این احتمال وجود دارد که کاربر از دستگاهی استفاده کند که فضای دیسک آن تقریباً تمام شده است و مرورگر شما را از ذخیره هر چیزی منع کند.
به‌همین دلیل، بسیار مهم است که همیشه مدیریت خطای مناسب را در کد IndexedDB خود پیاده‌سازی کنید. این یعنی به‌طور کلی ایده خوبی است که وضعیت برنامه را در حافظه نگه دارید (علاوه‌بر ذخیره کردن آن)، تا وقتی برنامه در حالت مرور خصوصی اجرا می‌شود یا وقتی فضای ذخیره‌سازی دردسترس نیست، واسط کاربر خراب نشود (حتی اگر برخی‌از ویژگی‌های دیگر برنامه که به فضای ذخیره‌سازی نیاز دارند کار نکنند).
ممکن است داده‌های ذخیره‌شده توسط کاربر اصلاح یا حذف شده باشد
برخلاف پایگاه‌های داده سمت سرور که در آن‌ها می‌توانید دسترسی غیرمجاز را محدود کنید، پایگاه‌های داده سمت کارخواه برای افزونه‌های مرورگر و ابزارهای توسعه‌دهنده دردسترس هستند، و کاربر می‌تواند آن‌ها را پاک کند.
اگرچه ممکن است برای کاربران غیرمعمول باشد که داده‌های ذخیره‌شده محلی خود را تغییر دهند، اما پاک کردن آن برای کاربران کاملاً رایج است. مهم است که برنامه‌تان بتواند هر دو مورد را بدون خطا مدیریت کند.
داده‌های ذخیره‌شده ممکن است قدیمی باشد
مشابه بخش قبلی، حتی اگر کاربر خودش داده‌ها را تغییر نداده باشد، ممکن است داده‌هایی که در فضای ذخیره‌سازی دارد توسط نسخه قبلی کد شما نوشته شده باشد، احتمالاً نسخه‌ای که اشکالاتی در آن وجود دارد.
IndexedDB از نسخه‌های طرح‌واره و ارتقا بااستفاده از روش
IDBOpenDBRequest.onupgradeneeded() خود پشتیبانی داخلی دارد؛ بااین‌حال، همچنان
باید کد ارتقا را به‌گونه‌ای بنویسید که بتواند کاربری را که از نسخه قبلی (ازجمله نسخه‌ای با اشکال) می‌آید مدیریت کند.
آزمایش‌های واحد می‌توانند در اینجا بسیار مفید باشند، زیرا اغلب آزمایش دستی همه مسیرها و موارد ارتقا امکان‌پذیر نیست.
حفظ عملکرد برنامه
یکی از ویژگی‌های کلیدی IndexedDB میانای برنامه‌سازی کاربردی ناهمگام آن است، اما این ویژگی نباید شما را فریب دهد که فکر کنید هنگام استفاده از آن نیازی به نگرانی درباره عملکرد ندارید. در برخی موارد، استفاده نادرست همچنان می‌تواند رشته اصلی را مسدود کند که می‌تواند منجر به عدم پاسخ‌گویی شود.
به‌عنوان یک قانون کلی، خواندن و نوشتن در IndexedDB نباید بزرگ‌تر از مقدار موردنیاز برای داده‌های دردسترس باشد.
درحالی‌که IndexedDB امکان ذخیره اشیای بزرگ و تودرتو را به‌عنوان یک رکورد واحد فراهم می‌کند (و انجام این کار از دیدگاه توسعه‌دهنده بسیار راحت است)، باید از این عمل اجتناب شود. دلیلش این است که وقتی IndexedDB شیئی را ذخیره می‌کند، ابتدا باید کلون ساختاریافته‌ای از آن شیء ایجاد کند، و فرایند کلون‌سازی ساختاریافته در رشته اصلی اتفاق می‌افتد. هرچه شیء بزرگ‌تر باشد، زمان مسدود شدن طولانی‌تر خواهد بود.
این امر چالش‌هایی را هنگام برنامه‌ریزی برای نحوه حفظ وضعیت برنامه در IndexedDB ایجاد می‌کند، زیرا اکثر کتابخانه‌های محبوب مدیریت وضعیت (مانند Redux) با مدیریت کل درخت وضعیت شما به‌عنوان یک شیء جاوا اسکریپت واحد کار می‌کنند.
While managing state in this way has many benefits, and while storing the entire state tree as a single record in IndexedDB may be tempting and convenient, doing this after every change (even if throttled/debounced) will result in unnecessary blocking for of the main thread, it will increase the likelihood of write errors, and in some cases it will even cause the browser tab to crash or become unresponsive.
به‌جای ذخیره کردن کل درخت وضعیت در یک سابقه، باید آن را به سابقه‌های جداگانه تقسیم کنید و فقط سابقه‌هایی را که واقعاً تغییر می‌کنند به‌روز کنید.
مانند اکثر روال‌های مطلوب، این یک قانون همه‌یاهیچ نیست. در مواردی که تجزیه شیء وضعیت و نوشتن حداقل مجموعه تغییرات امکان‌پذیر نیست، تجزیه داده‌ها به زیردرخت‌ها و نوشتن فقط آن‌ها همچنان بر نوشتن کل درخت وضعیت ترجیح دارد. بهبودهای کوچک بهتر از هیچ بهبودی است.
درنهایت، همیشه باید تأثیر عملکرد کدی را که می‌نویسید بسنجید. اگرچه درست است که نوشتن‌های کوچک در IndexedDB عملکرد بهتری نسبت‌به نوشتن‌های بزرگ دارند، اما این موضوع تنها زمانی اهمیت دارد که نوشتن‌های IndexedDB که برنامه شما انجام می‌دهد واقعاً منجر به وظایف طولانی شود که رشته اصلی را مسدود کرده و تجربه کاربری را کاهش دهد. مهم است که اندازه‌گیری کنید تا بدانید برای چه چیزی بهینه‌سازی می‌کنید.
نتیجه‌گیری‌ها
توسعه‌دهندگان می‌توانند از سازوکارهای ذخیره‌سازی کارخواه مانند IndexedDB برای بهبود تجربه کاربری برنامه‌شان استفاده کنند. این کار نه‌تنها با حفظ وضعیت در جلسات مختلف انجام می‌شود، بلکه با کاهش زمان لازم برای بارگیری وضعیت اولیه در بازدیدهای تکراری نیز صورت می‌گیرد.
درحالی‌که استفاده صحیح از IndexedDB می‌تواند تجربه کاربری را به‌طور چشمگیری بهبود بخشد، استفاده نادرست از آن یا عدم رسیدگی به موارد خطا می‌تواند منجر به خرابی برنامه‌ها و نارضایتی کاربران شود.
ازآنجایی‌که فضای ذخیره‌سازی مشتری شامل عوامل زیادی خارج از کنترل شما است، بسیار مهم است که کد شما به‌خوبی آزمایش شود و خطاها را به‌درستی مدیریت کند، حتی خطاهایی که ممکن است در ابتدا وقوع آن‌ها بعید به‌نظر برسد.