localStorage ليس شريرًا. إنه فقط من السهل إساءة استخدامه.
يعمل بشكل جيد بالنسبة لـ:
- تفضيل السمة
- ذاكرة تخزين صغيرة لعلم الميزات
- تلميحات جلسة خفيفة الوزن
إنه غير مناسب لـ:
- مجموعات البيانات الكبيرة غير المتصلة
- أنظمة المسودات التي تحتوي على الكثير من المحتوى
- قوائم العمليات المتزامنة
- الأحمال الصورية أو الثنائية
القيد الرئيسي
واجهة برمجة التطبيقات (API) متزامنة.
هذا يعني أن عمليات القراءة والكتابة تحدث على الخيط الرئيسي، وهو المكان الذي لا ترغب في حدوث عمل التخزين الكبير فيه في التطبيق الحديث.
بالنسبة للمفاتيح الصغيرة، يكون ذلك عادةً مقبولًا.
لكن بالنسبة لمجموعات التخزين بحجم التطبيق، يصبح ذلك رائحة تصميم.
متى يكون IndexedDB الخيار الأفضل
IndexedDB هو الخيار الأفضل عندما تحتاج إلى:
- سجلات منظمة
- الوصول غير المتزامن
- المعاملات
- الاستمرارية على جانب العميل الأكبر
لهذا السبب، تنتهي معظم تطبيقات الويب الجادة القابلة للعمل في وضع غير متصل إلى هناك في النهاية.
الجانب السلبي هو عامل ergonomics. واجهة البرمجة الكبيرة ليست ممتعة للاستخدام مباشرةً.
لماذا تساعد المكتبات
تجعل المكتبات مثل Dexie التعامل مع IndexedDB أسهل بكثير كجزء من بنية التطبيق بدلاً من كونه شيء غريب على مستوى المتصفح.
import Dexie, { type EntityTable } from "dexie";
interface Draft {
id: number;
title: string;
body: string;
}
const db = new Dexie("writer") as Dexie & {
drafts: EntityTable<Draft, "id">;
};
db.version(1).stores({
drafts: "++id, title",
});
كثيرًا ما يكون هذا كافيًا لجعل الاستمرارية على جانب المتصفح تبدو قابلة للصيانة.
قاعدة أفضل
استخدم:
localStorage لحالة صغيرة تشبه التفضيل- IndexedDB لبيانات التطبيقات الحقيقية
هذا الخط سيوفر العديد من آلام بنية الواجهة الأمامية.
قراءات إضافية