اسمحوا لي الآن أن أقدم لكم لمحة موجزة عن تطبيقات الصفحة الواحدة.
ما هي تطبيقات الصفحة الواحدة؟
كيف تختلف عن مواقع الويب التي قد تكون قد طورتها في وقت سابق؟
على سبيل المثال، موقع الويب الذي قمت بتطويره في الدورة السابقة لهذا التخصص،
حيث كان لديك صفحات متعددة - لماذا تعتبر تطبيقات الصفحة الواحدة مثيرة للاهتمام
وما الذي يجب أن تكون على علم به
عند تصميم تطبيقات الصفحة الواحدة؟
ليس المقصود من هذه المحاضرة أن تكون رسالة كاملة حول تطبيقات الصفحة الواحدة،
ولكن في الحقيقة، تعطيك ما يكفي من مقدمة
لبدء التفكير في تطبيقات الصفحة الواحدة،
وخاصة في سياق الزاوي.
قبل أن نفهم تطبيقات الصفحة الواحدة، دعونا نأخذ خطوة إلى الوراء
وننظر في كيفية عمل المواقع التقليدية.
في المواقع التقليدية، حتى الآن - إذا قمت بزيارة موقع ويب،
قد تطلب الوصول إلى صفحة معينة.
على سبيل المثال، سوف تطلب صفحة index.html
عند الانتقال إلى موقع الويب،
إما عن طريق النقر على رابط
أو عن طريق كتابة عنوان الموقع في شريط العناوين في متصفحك.
لذا عادة، تكون صفحة index.html هي أول صفحة
تجلبها عند زيارة موقع ويب.
وعندما يتم تنزيل الصفحة من الخادم إلى متصفحك -
ومن ثم سيتم عرض هذا في متصفحك.
الآن قد يتضمن هذا ليس فقط صفحة index.html، ولكن أيضا الموارد الأخرى
التي قد تكون هناك حاجة ليتم تحميلها من أجل بناء صفحة index.html.
في هذه الحالة، قد تتطلب صفحة index.html موارد إضافية،
مثل الصور أو البيانات، ليتم تحميلها قبل إنشاء صفحة الفهرس.
ولكن الآن، في وقت لاحق، إذا انتقلت إلى صفحة أخرى في موقع الويب الخاص بك
- على سبيل المثال، صفحة أخرى مثل contactus.html،
سيؤدي ذلك إلى إرسال متصفحك طلبًا آخر
إلى الخادم لجلب تلك الصفحة الثانية.
لذلك سيتم بدء طلب كامل إلى الخادم
وجميع الموارد اللازمة لبناء
الصفحة الثانية يجب تحميلها من الخادم.
لذلك أثناء الانتقال من صفحة إلى صفحة أخرى،
فإنه يتضمن كل صفحة جديدة ليتم تحميلها من الخادم
وهذا ينطوي على وقت ذهابا وإيابا
إلى الخادم لجلب جميع الموارد المطلوبة لبناء تلك الصفحات.
الآن تخيل أن موقع الويب الخاص بك يحتوي على العديد من الصفحات.
ثم من الواضح أن كل قطعة واحدة
تتطلب صفحة الويب الخاصة بك لتقديم سوف تتطلب وقت رحلة كاملة ذهابا وإيابا إلى الخوادم.
ما تلاحظه هو - في كثير من الأحيان هو أن العديد من هذه الصفحات لديها الكثير من القواسم المشتركة.
ربما، على سبيل المثال،
الرأس والتذييل وبعض المعلومات الأخرى كلها شائعة في كل هذه الصفحات.
ولكن لا يزال، يتطلب منك كل طلب صفحة جديدة
- للذهاب وجلب الصفحة بأكملها من الخادم.
الآن مع استخدام التخزين المؤقت على موقع المتصفح، يمكنك تخفيف بعض هذه المشاكل
عن طريق إعادة استخدام الموارد
التي تم جلبها بالفعل من ذاكرة التخزين المؤقت الخاصة بك؛ ولكن لا يزال، تتطلب كل صفحة جديدة تنتقل
إليها صفحة كاملة ليتم إعادة تحميلها من موقع الخادم.
تقترب تطبيقات الصفحة الواحدة من هذه المشكلة بطريقة مختلفة.
في تطبيق صفحة واحدة، عادة ما قمنا بتطوير تطبيق ويب
لذلك عندما ينتقل المتصفح إلى موقع الويب،
ثم هذا سوف يطلب تحميل تطبيق الويب من موقع الخادم.
لذلك سيكون هذا، على سبيل المثال، موجودًا في صفحة رئيسية مثل index.html،
والتي ستؤدي إلى تشغيل مجموعة كاملة من الأصول
المطلوبة لعرض تطبيق الويب الخاص بك ليتم تنزيله إلى موقع العميل الخاص بك.
الآن كيف يتم حزم هذه الأصول يعتمد على كيفية تصميم تطبيق الويب الخاص بك
وأيضا ما هو الإطار الذي تستخدمه لتصميم تطبيق الويب الخاص بك.
ولكن مع ذلك، لديك واحد تحميل كبير واحد في بداية تطبيق الويب الخاص بك.
ستؤدي التغييرات اللاحقة على موقع العميل، على سبيل المثال، التي بدأتها بنقرة على رابط، إلى بدء طلب جديد لموقع الخادم؛ ولكن في هذه الحالة، في
كثير من الأحيان، تقوم بتنزيل بعض البيانات فقط، ربما في شكل بيانات JSON،
من موقع الخادم.
لذلك في هذه الحالة، قد يتطلب كل منها الوصول إلى الخادم
فقط لتنزيل بيانات JSON، على سبيل المثال،
والتي قد تمكنك بعد ذلك من عرض العرض الجديد بالكامل
في تطبيق الصفحة الواحدة الخاص بك.
وبالتالي فإن تحميل الصفحة الأولية، تحميل التطبيق الأولي، بطبيعة الحال،
هو دائما هناك، ولكن معظم التفاعلات اللاحقة مع الخادم
سيكون ببساطة لتحميل البيانات، وعادة في شكل جسون أو شمل،
اعتمادا على كيفية تصميم تنسيق البيانات الخاص بك.
وبمجرد تنزيل البيانات
، يمكن استخدام هذه البيانات لعرض العرض الجديد داخل التطبيق الخاص بك.
لذلك في هذه الظروف،
سوف توفر الكثير من الوقت ذهابا وإيابا إلى الخادم لتحميل الكثير من الأصول.
وبطبيعة الحال، يتطلب تحميل الصفحة الأولي قدرا من العمل الذي يتعين القيام به،
ولكن الطلبات اللاحقة قد تكون لكميات صغيرة جدا من البيانات.
وهذا، في الواقع، هو السمة الهامة لتطبيقات الصفحة الواحدة.
الآن مع التقديم المسبق لبعض وجهات نظرهم على موقع الخادم نفسه،
يمكنك حتى تخفيف بعض وقت التنزيل الأولي لتطبيق الويب الخاص بك.
لذلك، حتى Angular، على سبيل المثال،
تمكنك من تقديم جزء من العرض الأول على موقع الخادم
لتمكين عرض المعلومات للعميل بسرعة،
بينما يتم تنزيل بقية تطبيق الويب بواسطة متصفحك.
حتى نتمكن من تلخيص أن تطبيقات الصفحة الواحدة
كتطبيق ويب على موقع ويب يناسب في صفحة واحدة - مرة أخرى،
تعطي أو تأخذ - كما تعلمون، لا تفسر ذلك حرفيا جدا.
لذلك لا تحتاج إلى إعادة تحميل صفحة بأكملها مرة أخرى.
لذلك هذه هي الميزة الهامة لتطبيق صفحة واحدة.
كذلك، تمكنك تطبيقات الصفحة الواحدة من تقديم تجربة مستخدم
أقرب للعمل الذي يرونه مع تطبيقات سطح المكتب.
بمجرد تنزيل تطبيق الويب الأولي؛ بعد ذلك،
ستبدو معظم التفاعلات الأخرى وكأنك تتفاعل مع تطبيق سطح المكتب.
لذلك لتلخيص ما تعلمناه للتو، ما هو تطبيق صفحة واحدة؟
تطبيق صفحة واحدة هو تطبيق ويب أو موقع ويب يتناسب مع صفحة واحدة.
لا تحتاج إلى إعادة تحميل الصفحة بأكملها في كل مرة يتفاعل فيها المستخدم
مع التطبيق.
و أوك هو أشبه سطح المكتب أو التطبيق الأصلي.
يتم تنزيل معظم الموارد المطلوبة للتطبيق الخاص بك في المقام الأول نفسه، مع تحميل الصفحة الأولى.
بعد ذلك، يتم إعادة رسم أجزاء فقط من الصفحة،
استنادًا إلى كيفية حدوث تفاعل المستخدم دون الحاجة إلى خادم كامل ذهابًا وإيابًا،
لجلب جميع الموارد التي تحتاجها.
وبطبيعة الحال، فإن هذا لا يأتي دون مجموعته الخاصة من القضايا التي تحتاج إلى معالجة.
لذلك عند تصميم تطبيقات صفحة واحدة، واحدة من أول الأشياء
التي غالبا ما يتساءل الناس عن تطبيقات الصفحة الواحدة
هي أنها ليست الأمثل لمحركات البحث.
لذا فإن تحسين محرك البحث هو جزء مهم يحتاج إلى معالجة.
لذلك إذا كان لديك محركات بحث
تزحف موقعك على الويب لاستخراج البيانات ومعلومات الفهرس،
فقد لا تكون تطبيقات الصفحة الواحدة بالضرورة تعاونية في هذه الحالة.
ولكن حتى تحسين محرك البحث مع أطر البيانات الحالية،
مثل Angular، قد حان بعيدا على الطريق أنه حتى مع تطبيق الصفحة الواحدة،
يمكن لمحركات البحث فهرسة الكثير من المعلومات
التي يخدمها تطبيق الويب الخاص بك.
المشكلة الثانية التي يجب معالجتها هي مقدار بناء الويب الذي يجب إلغاء تحميله
إلى موقع العميل بدلاً من موقع الخادم.
لذا فإن الخادم يعمل إلى حد كبير كمصدر بيانات في تطبيقات الصفحة الواحدة
ويتم إلغاء تحميل الكثير من العمل إلى موقع العميل.
من منظور واحد،
يمنحك هذا طريقة أكثر قابلية للتطوير لتقديم تطبيق الويب الخاص
بك إلى موقع العميل الخاص بك، لأن الكثير من عمل التقديم يتم على موقع العميل.
الآن يمكنك تحسين هذا إلى حد ما لتعويض التنزيل الأولي
لتطبيق الويب من موقع الخادم عن
طريق القيام بجزء من التقديم على موقع الخادم.
كما ذكرت، يوفر لك Angular فرصة
للقيام بذلك مع عرض موقع الخادم الجزئي
للعرض الأولي لتطبيقك.
الجانب الثالث هو كيفية الحفاظ على التاريخ حتى عند النقر على زر العودة
أو زر الأمام، إلى أين يمكنك أن تأخذ المستخدم ل؟
هل يمكنك حفظ ما يكفي من المعلومات
التي سوف تكون قادرة على التنقل بين وجهات النظر المختلفة من التطبيق الخاص بك وهلم جرا؟
لذلك هذا هو الشيء الوحيد الذي تحتاج إلى أن تأخذ في الاعتبار.
بالطبع، لأن جهاز التوجيه Angular يعزز واجهة برمجة تطبيقات التاريخ المكون من خمس صفحات html،
لذلك فهو قادر على معالجة هذه المشكلة إلى حد كبير.
السؤال الأخير الذي لدينا هو التحليلات.
كيف تدعم التحليلات على صفحة الويب الخاصة بك؟
كيف يمكنك جمع بيانات التحليلات وما إلى ذلك؟
وأيضا، كما ذكرت سابقا، تسريع تحميل الصفحة الأولية
هو شيء يثير القلق عندما كنت تصميم تطبيق الويب الخاص بك.
الآن مع Angular، كما قلت،
سيؤدي إجراء عرض جزئي على جانب الخادم إلى تسريع تحميل الصفحة الأولية
على موقع العميل الخاص بك بينما
يتم تنزيل بقية تطبيق الويب إلى موقع العميل.
حتى تتمكن من إخفاء القليل من وقت التحميل الأولي لتطبيق الويب عن
طريق إجراء عرض جزئي من موقع الخادم نفسه.
مع وضع هذه الأفكار الأساسية في الاعتبار،
دعنا نذهب الآن ونستكشف كيف يدعم Angular تطبيقات الصفحة الواحدة.
لقد أدمجنا بالفعل جهاز التوجيه الزاوي
في تطبيقنا الزاوي في التمرين السابق.
في التدريبات اللاحقة في هذا الدرس
والمهمة، سوف نكمل تطوير تطبيق الصفحة الواحدة
الذي كنا نعمل عليه حتى الآن في هذا المساق.