التوجيه القائم على Hash في مقابل التوجيه القائم على Path

تحتاج تطبيقات SPA إلى عناوين URL لا يجلبها المتصفح. هناك نهجان: يستخدم التوجيه المعتمد على الهاش الجزء اللاحق للرمز #، والذي لا يرسله المتصفح إلى الخادم مطلقًا، بينما يستخدم التوجيه المعتمد على المسار اسم المسار مع بعض حيل History API.

تبدو عناوين URL مثل https://example.com/#/about. لا يرى الخادم سوى / ويقدّم HTML نفسه لكل عنوان URL. يقرأ JavaScript من جانب العميل location.hash لتحديد العرض الذي يجب عرضه. وهذا حل بسيط لا يتطلب إعدادًا للخادم.

يستمع جهاز التوجيه المعتمد على الهاش إلى حدث hashchange الذي يُطلَق كلما تغيّرت location.hash. وبالاقتران مع قراءة window.location.hash، تمثل هذه كل واجهة API اللازمة للتوجيه من جانب العميل — من دون استخدام History API.

تبدو عناوين URL مثل https://example.com/about — ولا يمكن تمييزها عن العناوين التي يعرضها الخادم. يغيّر pushState في History API المسار دون إعادة تحميل؛ ويُطلَق popstate عند التنقّل إلى الخلف أو إلى الأمام؛ ويحوّل اعتراض النقرات على عناصر <a> إلى تنقّل في SPA.

في التوجيه المعتمد على المسار، يجب أن يعيد الخادم ملف index.html الخاص بتطبيق SPA لأي مسار قد يدخله المستخدم مباشرةً أو يعيد تحميله. وإلا فستؤدي إعادة تحميل /about إلى خطأ 404. الإعداد المطلوب هو: جرّب الملف، ثم استخدم index.html كخيار احتياطي، كما في history fallback في Nginx وvite-plugin-history-api في Vite dev.

لا تستطيع محركات البحث وكثير من الأدوات الزحف إلى أجزاء الهاش إطلاقًا — فالمحتوى الموجود في /#/about غير مرئي لبرامج الزحف القديمة، مع أن Google يتعامل معه عبر العرض دون واجهة رسومية وقد لا تفعل الأدوات الأخرى ذلك. أما عناوين URL المعتمدة على المسار فيجري الزحف إليها بشكل طبيعي، مما يجعلها أفضل بكثير لتحسين الظهور في محركات البحث.

تبدو عناوين URL المعتمدة على الهاش «غريبة» بوضوح — إذ يلاحظ المستخدمون الرمز # وقد لا يثقون بالرابط أو يتذكرون نسخ عنوان URL كاملًا. أما عناوين URL المعتمدة على المسار فتبدو مثل أي عنوان ويب آخر، وهذا ما يتوقعه المستخدمون. ولهذا السبب وحده تقريبًا، تختار تطبيقات SPA الحديثة التوجيه المعتمد على المسار.

التوجيه المعتمد على الهاش: نحو 10 أسطر من JavaScript، تشمل مستمع hashchange والعرض. أما التوجيه المعتمد على المسار فيتطلب استدعاءات pushState ومستمع popstate واعتراض نقرات الروابط وخيارًا احتياطيًا من جهة الخادم. الهاش هو الخيار الأخف ممكنًا؛ بينما يتطلب المسار بنية تحتية أكبر لتوفير تجربة مستخدم أفضل.

لا تستطيع الاستضافات الثابتة البحتة، مثل الإعداد الافتراضي لـ GitHub Pages، تنفيذ الخيار الاحتياطي من جهة الخادم، لذلك يتعطل التوجيه المعتمد على المسار عند إعادة التحميل. تشمل الحلول الالتفافية حيل إعادة التوجيه عبر 404.html، أو الاستضافة على Netlify أو Vercel اللذين يفهمان الخيار الاحتياطي لتطبيقات SPA، أو قبول التوجيه المعتمد على الهاش في المشاريع المخصصة للاستضافة الثابتة فقط.

تجمع بعض التطبيقات بين النهجين: التوجيه المعتمد على المسار للمسار الأساسي، والهاش للأقسام داخل الصفحة، مثل النوافذ المشروطة ومراسي الألسنة. ويظل حدث hashchange يُطلَق لهذه الحالات، ليكمّل جهاز التوجيه المعتمد على History في حالة الصفحة الفرعية دون إفساد عنوان URL الرئيسي.

للترحيل من الهاش إلى المسار: أعد كتابة جميع الروابط الداخلية، وأضف خيارًا احتياطيًا للخادم، واستبدل منطق hashchange بـ popstate، وأعد توجيه عناوين URL القديمة التي تستخدم الهاش إلى نظيراتها المعتمدة على المسار باستخدام نص تمهيدي صغير يُشغّل مرة واحدة ويستدعي history.replaceState.

اختر التوجيه المعتمد على الهاش في الحالات التالية: الاستضافات الثابتة التي لا تدعم إعادة الكتابة، وأدوات الإدارة الداخلية التي لا تهمها محركات البحث، والعناصر المضمّنة. واختر التوجيه المعتمد على المسار في الحالات التالية: كل ما يواجه المستخدمين، وكل ما ينبغي فهرسته في محركات البحث، وكل ما ستتم مشاركته على الشبكات الاجتماعية — وهذا يشمل معظم التطبيقات.

لا يحتاج التوجيه المعتمد على الهاش، بعناوين URL مثل /#/about، إلى إعداد للخادم، لكنه يعاني من ضعف الظهور في محركات البحث ويستخدم عناوين URL غير أنيقة. أما التوجيه المعتمد على المسار، بعناوين URL مثل /about، فيحتاج إلى خيار احتياطي من الخادم يعيد index.html، لكنه ينتج عناوين URL نظيفة وملائمة لمحركات البحث وسهلة المشاركة. تستخدم تطبيقات SPA الحديثة الموجهة للجمهور التوجيه المعتمد على المسار؛ بينما قد تختار المشاريع المستضافة استاتيكيًا أو الداخلية الهاش لبساطته.