Storage API في الإضافات: local و sync و session من منظور العزل

Extension settings قد تبدو ك key/value بسيطة، لكن local و sync و session تخدم أغراضًا مختلفة. في متصفح متعدد البروفايلات يجب إضافة سؤال آخر: هل كل نوع storage معزول per-profile كما يتوقع المنتج؟ حتى لو Chromium يوفر behavior معيّنًا، customization أو extension host مشترك قد يغير النتيجة.

استخدم local للبيانات الدائمة المحلية

مناسبة preferences غير الحساسة التي يجب أن تبقى بعد restart، مع فهم quota و scope. لا تضع secrets plaintext لمجرد أن التخزين local.

افهم sync قبل استخدامها

sync قد تنتقل عبر حساب browser في Chrome التقليدي وتملك quotas وسلوك conflict. في منتج مخصص تحقق هل مدعومة وكيف تُعزل. لا تجعل إعداد حساب تجاري ينتقل إلى profile أخرى بلا قصد.

استخدم session للحالة المؤقتة

Storage session مناسبة لحالة runtime لا تحتاج بعد restart، لكنها ليست بديلًا لكل global variable. اختبر lifecycle في MV3 وانتهاءها عند إغلاق السياق.

اختبر Isolation لكل Area

اكتب marker مختلفًا في A/B لكل storage area ثم restart. هذا يكشف إن كان أحدها global في implementation لديك.

صمم Schema و Versioning

حتى key/value تحتاج migration. ضع version واكتب migration idempotent. لا تغير معنى key قديم بصمت وتترك profiles على أشكال مختلفة.

راقب Quota والأخطاء

Writes قد تفشل بسبب quota أو rate. لا تتجاهل Promise rejection. Batch updates أفضل من كتابة كل keystroke، خصوصًا sync.

وفر Clear محدود

زر Reset للإضافة يجب أن يمس namespace الخاصة بها والبروفايل الحالي، لا storage لكل extensions. اعرض ما سيُحذف عند البيانات المهمة.

اختبر الإضافة داخل دورة الحياة كاملة

عند التعامل مع «Storage API في الإضافات: local و sync و session من منظور العزل» لا تكتفِ بتثبيت الإضافة وفتح popup. اختبر التثبيت والترقية وإعادة تشغيل المتصفح وتعليق service worker وإزالته، ثم تأكد من تنظيف listeners والتخزين الذي لم يعد مطلوبًا. شغّل السيناريو داخل بروفايلين للتأكد أن الحالة لا تتسرب بينهما، وجرب رفض permission ثم منحها ثم سحبها. إذا كانت هناك content scripts، راقب توقيت الحقن عند navigation و SPA transitions. بهذه المجموعة تظهر مشاكل لا تراها تجربة يدوية قصيرة بعد التثبيت مباشرة.

معيار القبول قبل الإغلاق

اختبر أثر الترقية وليس التثبيت النظيف فقط. احتفظ ببروفايل على النسخة السابقة ثم حدث الإضافة وراجع storage migrations وال permissions وال background lifecycle. أي warning جديد في console أو extension errors يجب تصنيفه قبل التعميم على كل البروفايلات.

حالة فشل يجب اختبارها

في «Storage API في الإضافات: local و sync و session من منظور العزل» جرّب صفحة لا تطابق نطاق الإضافة ثم صفحة تطابقه جزئيًا. تأكد أن content script وال ـhost permissions لا تتوسع بسبب wildcard أوسع من الحاجة، وأن تعطيل الإضافة يوقف listeners والرسائل فورًا. هذه الاختبارات تكشف حدود النطاق أكثر من مجرد التأكد أن الميزة تعمل.

توثيق النتيجة للفريق

بعد الانتهاء من اختبار «Storage API في الإضافات: local و sync و session من منظور العزل»، احفظ ملخصًا قصيرًا يوضح البيئة والخطوات والنتيجة وما الذي تغير عن ال ـbaseline. أرفق أكواد الأخطاء أو المقاييس الضرورية فقط، واربطها برقم الإصدار. هذا السجل يجعل المراجعة اللاحقة أسرع ويمنع إعادة نفس النقاش من الصفر، كما يسمح لفريق آخر بتكرار التجربة دون الاعتماد على ذاكرة الشخص الذي نفذها. إذا كانت النتيجة غير حاسمة، اكتب ذلك صراحة وحدد الاختبار التالي بدل تحويل الاحتمال إلى استنتاج نهائي.