إنّ استخدام History API لإدارة عناوين URL أمر رائع، كما أنّه يُعدّ ميزة أساسية لتطبيقات الويب الجيدة. من سلبيات هذا الإعداد أنّه يتم تخزين مواضع التمرير، ثم استعادتها عند التنقّل في السجلّ، وهو أمر مهم. ويؤدي ذلك غالبًا إلى حدوث قفزات غير مرغوب فيها عند تغيير موضع التمرير تلقائيًا، لا سيما إذا كان تطبيقك يُجري عمليات انتقال أو يغيّر محتوى الصفحة بأي شكل من الأشكال. في النهاية، يؤدي ذلك إلى تقديم تجربة سيئة للمستخدم.
ما يزيد الطين بلة أنّه لا يمكنك فعل الكثير حيال ذلك: يشغّل Chrome حدث popState قبل حدث scroll، ما يعني أنّه يمكنك قراءة موضع التمرير الحالي في popState ثم عكسه في معالِج حدث scroll باستخدام window.scrollTo (يبدو الأمر غريبًا، ولكنّه يعمل على الأقل). ومع ذلك، يُشغِّل Firefox حدث scroll قبل popState، لذا لا يمكنك معرفة قيمة الانتقال السابقة لاستعادتها. باه!
الخبر السار هو أنّ هناك حلّاً محتملاً: history.scrollRestoration. يقبل هذا المَعلمة قيمتَي سلسلة: auto التي تحافظ على كل شيء كما هو اليوم (وهي القيمة التلقائية) وmanual التي تعني أنّك بصفتك المطوّر ستتولى ملكية أي تغييرات في الانتقال إلى أعلى أو أسفل الصفحة قد تكون مطلوبة عندما ينتقل المستخدم إلى سجلّ التطبيق. يمكنك تتبُّع موضع التمرير عند دفع إدخالات السجلّ باستخدام history.pushState() إذا أردت ذلك.
هذه الميزة جديدة وتجريبية (ورائعة جدًا)، لذا تأكَّد من توفّرها قبل استخدامها:
if ('scrollRestoration' in history) {
// Back off, browser, I got this...
history.scrollRestoration = 'manual';
}
يمكنك العثور على history.scrollRestoration في الإصدار 46 من Chrome فصاعدًا، ويمكنك الاطّلاع على مواصفاته هنا.
يُرجى إرسال ملاحظاتك إلينا وإعلام المورّدين الآخرين إذا أردت منهم توفير scrollRestoration أيضًا.