بهترین روش ها برای همگام سازی وضعیت برنامه بین IndexedDB و کتابخانه های مدیریت دولتی محبوب را بیاموزید.
هنگامی که کاربر برای اولین بار یک وب سایت یا برنامه را بارگذاری می کند، معمولاً مقدار زیادی کار در ساخت حالت اولیه برنامه که برای رندر UI استفاده می شود، انجام می شود. به عنوان مثال، گاهی اوقات برنامه نیاز به احراز هویت کاربر سمت مشتری دارد و سپس چندین درخواست API را قبل از اینکه تمام داده‌هایی را که برای نمایش در صفحه دارد داشته باشد، انجام دهد.
ذخیره وضعیت برنامه در IndexedDB می تواند یک راه عالی برای سرعت بخشیدن به زمان بارگذاری برای بازدیدهای مکرر باشد. سپس این برنامه می‌تواند با هر سرویس API در پس‌زمینه همگام‌سازی شود و با استفاده از استراتژی اعتبارسنجی مجدد ، رابط کاربری را با داده‌های جدید به‌روزرسانی کند.
با این حال، هنگام استفاده از IndexedDB موارد مهم زیادی وجود دارد که باید در نظر بگیرید که ممکن است بلافاصله برای توسعه دهندگانی که به API ها تازه کار هستند آشکار نباشد. این سند به سوالات رایج پاسخ می‌دهد و برخی از مهم‌ترین چیزهایی را که باید در هنگام تداوم وضعیت برنامه در IndexedDB در نظر داشت، مورد بحث قرار می‌دهد.
برنامه خود را قابل پیش بینی نگه دارید
بسیاری از پیچیدگی‌های پیرامون IndexedDB از این واقعیت ناشی می‌شود که عوامل بسیاری وجود دارد که شما (توسعه‌دهنده) کنترلی روی آنها ندارید. این بخش بسیاری از مسائلی را که باید هنگام کار با IndexedDB در نظر داشته باشید بررسی می کند.
ممکن است نوشتن در فضای ذخیره‌سازی ناموفق باشد
خطاها هنگام نوشتن در IndexedDB می تواند به دلایل مختلفی رخ دهد و در برخی موارد این دلایل خارج از کنترل شما به عنوان یک توسعه دهنده است. برای مثال، برخی از مرورگرها در حالت مرور خصوصی اجازه نوشتن در IndexedDB را نمی‌دهند. همچنین این احتمال وجود دارد که کاربر در دستگاهی باشد که فضای دیسک تقریباً تمام شده است و مرورگر شما را از ذخیره کردن هر چیزی محدود می کند.
به همین دلیل، بسیار مهم است که همیشه مدیریت صحیح خطا را در کد IndexedDB خود پیاده سازی کنید. این همچنین به این معنی است که عموماً ایده خوبی است که وضعیت برنامه را در حافظه نگه دارید (علاوه بر ذخیره آن)، بنابراین هنگام اجرا در حالت مرور خصوصی یا زمانی که فضای ذخیره سازی در دسترس نیست (حتی اگر برخی از موارد دیگر، رابط کاربری خراب نشود) ویژگی های برنامه ای که به فضای ذخیره سازی نیاز دارند کار نمی کنند).
داده های ذخیره شده ممکن است توسط کاربر اصلاح یا حذف شده باشد
برخلاف پایگاه‌های داده سمت سرور که می‌توانید دسترسی غیرمجاز را محدود کنید، پایگاه‌های داده سمت سرویس گیرنده برای افزونه‌های مرورگر و ابزارهای توسعه‌دهنده قابل دسترسی هستند و کاربر می‌تواند آنها را پاک کند.
در حالی که ممکن است برای کاربران تغییر داده های ذخیره شده محلی خود غیر معمول باشد، پاک کردن آن برای کاربران بسیار رایج است. مهم است که برنامه شما بتواند هر دوی این موارد را بدون خطا انجام دهد.
داده های ذخیره شده ممکن است قدیمی باشند
مشابه بخش قبل، حتی اگر کاربر خودش داده‌ها را اصلاح نکرده باشد، ممکن است داده‌هایی که در ذخیره‌سازی دارند توسط نسخه قبلی کد شما نوشته شده باشد، احتمالاً نسخه‌ای با اشکال در آن.
IndexedDB دارای پشتیبانی داخلی برای نسخه های طرحواره و ارتقاء با استفاده از روش IDBOpenDBRequest.onupgradeneeded() است. با این حال، همچنان باید کد ارتقای خود را به گونه‌ای بنویسید که بتواند با کاربر وارد شده از نسخه قبلی (از جمله نسخه دارای اشکال) کنترل کند.
تست‌های واحد در اینجا می‌توانند بسیار مفید باشند، زیرا اغلب امکان آزمایش دستی همه مسیرها و موارد ارتقاء ممکن نیست.
عملکرد برنامه خود را حفظ کنید
یکی از ویژگی های کلیدی IndexedDB API ناهمزمان آن است، اما اجازه ندهید که شما را فریب دهد و فکر کنید که در هنگام استفاده از آن نیازی به نگرانی در مورد عملکرد ندارید. تعدادی از موارد وجود دارد که استفاده نادرست همچنان می تواند رشته اصلی را مسدود کند، که می تواند منجر به عدم پاسخگویی شود.
به عنوان یک قاعده کلی، خواندن و نوشتن در IndexedDB نباید بزرگتر از مقدار مورد نیاز برای داده های مورد دسترسی باشد.
در حالی که IndexedDB امکان ذخیره اشیاء بزرگ و تودرتو به عنوان یک رکورد را فراهم می کند (و مسلماً انجام این کار از دیدگاه توسعه دهنده بسیار راحت است)، باید از این عمل اجتناب شود. دلیل آن این است که وقتی IndexedDB یک شی را ذخیره می‌کند، ابتدا باید یک کلون ساختاریافته از آن شی ایجاد کند و فرآیند شبیه‌سازی ساختاریافته در رشته اصلی اتفاق می‌افتد. هر چه جسم بزرگتر باشد، زمان مسدود شدن بیشتر خواهد بود.
این امر در هنگام برنامه ریزی چگونگی تداوم وضعیت برنامه در IndexedDB چالش هایی را ایجاد می کند، زیرا اکثر کتابخانه های مدیریت دولتی محبوب (مانند Redux ) با مدیریت کل درخت حالت شما به عنوان یک شی جاوا اسکریپت کار می کنند.
در حالی که مدیریت وضعیت به این روش دارای مزایای بسیاری است، و در حالی که ذخیره کل درخت حالت به عنوان یک رکورد در IndexedDB ممکن است وسوسه انگیز و راحت باشد، انجام این کار پس از هر تغییر (حتی اگر throttle/debound شود) منجر به مسدود شدن غیر ضروری برای اصلی می شود. thread، احتمال خطاهای نوشتن را افزایش می دهد و در برخی موارد حتی باعث از کار افتادن تب مرورگر یا عدم پاسخگویی می شود.
به جای ذخیره کل درخت حالت در یک رکورد، باید آن را به رکوردهای جداگانه تقسیم کنید و فقط رکوردهایی را که واقعاً تغییر می کنند به روز کنید.
مانند بسیاری از بهترین شیوه ها، این یک قانون همه یا هیچ نیست. در مواردی که شکستن یک شیء حالت و نوشتن مجموعه تغییرات حداقل امکان پذیر نیست، شکستن داده ها به درختان فرعی و فقط نوشتن آن ها همچنان بر نوشتن کل درخت حالت ترجیح داده می شود. بهبودهای کوچک بهتر از عدم پیشرفت است.
در نهایت، همیشه باید تأثیر عملکرد کدی را که می‌نویسید اندازه‌گیری کنید . در حالی که درست است که نوشته‌های کوچک در IndexedDB بهتر از نوشتن‌های بزرگ عمل می‌کنند، این تنها در صورتی مهم است که نوشته‌های برنامه شما در IndexedDB واقعاً منجر به کارهای طولانی شود که رشته اصلی را مسدود کرده و تجربه کاربر را کاهش دهد. اندازه گیری بسیار مهم است تا بفهمید برای چه چیزی بهینه سازی می کنید.
نتیجه گیری
توسعه‌دهندگان می‌توانند از مکانیسم‌های ذخیره‌سازی کلاینت مانند IndexedDB برای بهبود تجربه کاربری برنامه‌شان استفاده کنند، نه تنها با تداوم وضعیت در جلسات، بلکه با کاهش زمان بارگذاری حالت اولیه در بازدیدهای مکرر.
در حالی که استفاده صحیح از IndexedDB می تواند تجربه کاربر را به طرز چشمگیری بهبود بخشد، استفاده نادرست از آن یا عدم رسیدگی به موارد خطا می تواند منجر به خراب شدن برنامه ها و کاربران ناراضی شود.
از آنجایی که ذخیره سازی مشتری شامل عوامل بسیاری خارج از کنترل شما می شود، بسیار مهم است که کد شما به خوبی آزمایش شده باشد و به درستی خطاها را کنترل کند، حتی آنهایی که ممکن است در ابتدا بعید به نظر برسد.