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