بناء تطبيق مصرفي الجزء 3: طرق جلب البيانات واستخدامها

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

⚡ ما يمكنك القيام به في الـ 5 دقائق القادمة

مسار البداية السريعة للمطورين المشغولين - الدقيقة 1-2: قم بتشغيل خادم API الخاص بك (cd api && npm start) واختبر الاتصال - الدقيقة 3: أنشئ وظيفة getAccount() الأساسية باستخدام fetch - الدقيقة 4: قم بتوصيل نموذج تسجيل الدخول بـ action=“javascript:login()” - الدقيقة 5: اختبر تسجيل الدخول وشاهد بيانات الحساب تظهر في وحدة التحكم أوامر الاختبار السريع: لماذا هذا مهم: في 5 دقائق، ستشاهد سحر جلب البيانات غير المتزامن الذي يدعم كل تطبيق ويب حديث. هذا هو الأساس الذي يجعل التطبيقات تبدو مستجيبة وحيوية.

🗺️ رحلتك التعليمية عبر تطبيقات الويب المعتمدة على البيانات

وجهة رحلتك: بنهاية هذا الدرس، ستفهم كيف تقوم تطبيقات الويب الحديثة بجلب ومعالجة وعرض البيانات ديناميكيًا، مما يخلق تجارب مستخدم سلسة نتوقعها من التطبيقات الاحترافية.

اختبار ما قبل المحاضرة

اختبار ما قبل المحاضرة

المتطلبات الأساسية

قبل الغوص في جلب البيانات، تأكد من أن لديك هذه المكونات جاهزة: - الدرس السابق: أكمل نموذج تسجيل الدخول والتسجيل - سنبني على هذا الأساس - الخادم المحلي: قم بتثبيت Node.js وتشغيل خادم API لتوفير بيانات الحساب - اتصال API: اختبر اتصال الخادم الخاص بك باستخدام هذا الأمر: هذا الاختبار السريع يضمن أن جميع المكونات تتواصل بشكل صحيح: - يتحقق من أن Node.js يعمل بشكل صحيح على نظامك - يؤكد أن خادم API الخاص بك نشط ويستجيب - يتحقق من أن تطبيقك يمكنه الوصول إلى الخادم (مثل التحقق من الاتصال اللاسلكي قبل بدء المهمة)

🧠 نظرة عامة على نظام إدارة البيانات

المبدأ الأساسي: تطبيقات الويب الحديثة هي أنظمة تنسيق البيانات - تنسق بين واجهات المستخدم وواجهات برمجة التطبيقات للخادم ونماذج أمان المتصفح لإنشاء تجارب سلسة ومستجيبة.

فهم جلب البيانات في تطبيقات الويب الحديثة

طريقة تعامل تطبيقات الويب مع البيانات تطورت بشكل كبير على مدار العقدين الماضيين. فهم هذا التطور سيساعدك على تقدير قوة التقنيات الحديثة مثل AJAX وFetch API ولماذا أصبحت أدوات أساسية لمطوري الويب. دعونا نستكشف كيف كانت تعمل المواقع التقليدية مقارنة بالتطبيقات الديناميكية المستجيبة التي نبنيها اليوم.

التطبيقات متعددة الصفحات التقليدية (MPA)

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

التطبيقات أحادية الصفحة الحديثة (SPA)

غيرت تقنية AJAX (JavaScript وXML غير المتزامن) هذا النموذج تمامًا. مثل التصميم المعياري لمحطة الفضاء الدولية، حيث يمكن لرواد الفضاء استبدال المكونات الفردية دون إعادة بناء الهيكل بالكامل، يسمح لنا AJAX بتحديث أجزاء محددة من صفحة الويب دون إعادة تحميل كل شيء. على الرغم من أن الاسم يشير إلى XML، إلا أننا نستخدم JSON في الغالب اليوم، لكن المبدأ الأساسي يبقى كما هو: تحديث ما يحتاج إلى التغيير فقط. لماذا التطبيقات أحادية الصفحة تبدو أفضل بكثير: - يتم تحديث الأجزاء التي تغيرت فقط (ذكي، أليس كذلك؟) - لا مزيد من الانقطاعات المزعجة - يبقى المستخدمون في تدفقهم - بيانات أقل تنتقل عبر الشبكة تعني تحميل أسرع - كل شيء يبدو سريعًا ومستجيبًا، مثل التطبيقات على هاتفك

التطور إلى Fetch API الحديث

توفر المتصفحات الحديثة Fetch API، الذي يحل محل XMLHttpRequest القديم. مثل الفرق بين تشغيل التلغراف واستخدام البريد الإلكتروني، يستخدم Fetch API الوعود لكتابة كود غير متزامن أنظف ويتعامل مع JSON بشكل طبيعي. الخلاصة: - يعمل بشكل رائع في Chrome وFirefox وSafari وEdge (بشكل أساسي في كل مكان يتواجد فيه المستخدمون) - فقط Internet Explorer يحتاج إلى مساعدة إضافية (وبصراحة، حان الوقت للتخلي عن IE) - يجهزك تمامًا لأنماط async/await الأنيقة التي سنستخدمها لاحقًا

تنفيذ تسجيل الدخول وجلب البيانات

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

الخطوة 1: إنشاء أساس وظيفة تسجيل الدخول

افتح ملف app.js الخاص بك وأضف وظيفة login جديدة. ستتعامل هذه الوظيفة مع عملية مصادقة المستخدم: لنقم بتفصيل هذا: - الكلمة المفتاحية async؟ تخبر JavaScript “مرحبًا، هذه الوظيفة قد تحتاج إلى الانتظار لبعض الأشياء” - نحن نحصل على النموذج الخاص بنا من الصفحة (لا شيء فاخر، فقط العثور عليه بواسطة معرفه) - ثم نقوم بسحب ما كتبه المستخدم كاسم مستخدم - إليك خدعة رائعة: يمكنك الوصول إلى أي إدخال نموذج بواسطة خاصية name - لا حاجة لاستدعاءات إضافية لـ getElementById!

الخطوة 2: إنشاء وظيفة جلب بيانات الحساب

بعد ذلك، سنقوم بإنشاء وظيفة مخصصة لجلب بيانات الحساب من الخادم. يتبع هذا نفس النمط مثل وظيفة التسجيل الخاصة بك ولكنه يركز على جلب البيانات: ما يحققه هذا الكود: - يستخدم Fetch API الحديث لطلب البيانات بشكل غير متزامن - يبني عنوان URL لطلب GET مع معلمة اسم المستخدم - يطبق encodeURIComponent() للتعامل بأمان مع الأحرف الخاصة في عناوين URL - يحول الاستجابة إلى صيغة JSON لتسهيل معالجة البيانات - يتعامل مع الأخطاء بشكل جيد عن طريق إرجاع كائن خطأ بدلاً من التعطل لماذا هذا مهم: - يمنع الأحرف الخاصة من كسر عناوين URL - يحمي من هجمات التلاعب بعناوين URL - يضمن أن الخادم يتلقى البيانات المقصودة - يتبع ممارسات البرمجة الآمنة

فهم طلبات HTTP GET

إليك شيء قد يفاجئك: عندما تستخدم fetch بدون أي خيارات إضافية، فإنه ينشئ تلقائيًا طلب GET. هذا مثالي لما نقوم به - طلب من الخادم “مرحبًا، هل يمكنني رؤية بيانات حساب هذا المستخدم؟” فكر في طلبات GET كطلب استعارة كتاب من المكتبة - تطلب رؤية شيء موجود بالفعل. طلبات POST (التي استخدمناها للتسجيل) تشبه أكثر تقديم كتاب جديد ليتم إضافته إلى المجموعة.

الخطوة 3: جمع كل شيء معًا

الآن الجزء الممتع - دعونا نربط وظيفة جلب بيانات الحساب بعملية تسجيل الدخول. هنا حيث كل شيء يتكامل: تتبع هذه الوظيفة تسلسلًا واضحًا: - استخراج اسم المستخدم من إدخال النموذج - طلب بيانات حساب المستخدم من الخادم - التعامل مع أي أخطاء تحدث أثناء العملية - تخزين بيانات الحساب والانتقال إلى لوحة التحكم عند النجاح

الخطوة 4: إنشاء مكان لبياناتك

تطبيقك يحتاج إلى مكان لتذكر معلومات الحساب بمجرد تحميلها. فكر في هذا كمكان ذاكرة قصيرة المدى لتطبيقك - مكان للحفاظ على بيانات المستخدم الحالي في متناول اليد. أضف هذا السطر في أعلى ملف app.js الخاص بك: لماذا نحتاج هذا: - يحافظ على بيانات الحساب متاحة من أي مكان في تطبيقك - البدء بـ null يعني “لا أحد مسجل الدخول بعد” - يتم تحديثه عندما يسجل شخص ما الدخول أو التسجيل بنجاح - يعمل كمصدر واحد للحقيقة - لا يوجد ارتباك حول من هو مسجل الدخول

الخطوة 5: توصيل النموذج الخاص بك

الآن دعونا نربط وظيفة تسجيل الدخول الجديدة الخاصة بك بنموذج HTML الخاص بك. قم بتحديث علامة النموذج الخاصة بك على هذا النحو: ما يفعله هذا التغيير الصغير: - يوقف النموذج من القيام بسلوك “إعادة تحميل الصفحة بالكامل” الافتراضي - يستدعي وظيفة JavaScript المخصصة الخاصة بك بدلاً من ذلك - يحافظ على كل شيء سلسًا ومشابهًا لتطبيق الصفحة الواحدة - يمنحك التحكم الكامل في ما يحدث عندما يضغط المستخدمون على “تسجيل الدخول”

الخطوة 6: تحسين وظيفة التسجيل الخاصة بك

للحفاظ على التناسق، قم بتحديث وظيفة register الخاصة بك لتخزين بيانات الحساب أيضًا والانتقال إلى لوحة التحكم: يوفر هذا التحسين: - انتقال سلس من التسجيل إلى لوحة التحكم - تجربة مستخدم متسقة بين تدفقات تسجيل الدخول والتسجيل - وصول فوري إلى بيانات الحساب بعد التسجيل الناجح

اختبار التنفيذ الخاص بك

حان الوقت لتجربته: 1. أنشئ حسابًا جديدًا للتأكد من أن كل شيء يعمل 2. حاول تسجيل الدخول باستخدام نفس بيانات الاعتماد 3. ألقِ نظرة على وحدة التحكم في المتصفح الخاص بك (F12) إذا كان هناك أي شيء يبدو غير صحيح 4. تأكد من أنك تصل إلى لوحة التحكم بعد تسجيل الدخول بنجاح إذا كان هناك شيء لا يعمل، لا داعي للذعر! معظم المشاكل يمكن حلها بسهولة مثل الأخطاء الإملائية أو نسيان تشغيل خادم API.

كلمة سريعة عن السحر عبر الأصل

قد تتساءل: “كيف يتحدث تطبيق الويب الخاص بي إلى خادم API هذا بينما يعملان على منافذ مختلفة؟” سؤال رائع! هذا يتعلق بشيء يواجهه كل مطور ويب في النهاية. في إعدادنا: - تطبيق الويب الخاص بك يعمل على localhost:3000 (خادم التطوير) - خادم API الخاص بك يعمل على localhost:5000 (الخادم الخلفي) - يتضمن خادم API رؤوس CORS التي تسمح صراحةً بالاتصال من تطبيق الويب الخاص بك هذا التكوين يعكس تطوير العالم الحقيقي حيث تعمل التطبيقات الأمامية والخلفية عادةً على خوادم منفصلة.

إحياء بياناتك في HTML

الآن سنجعل البيانات التي تم جلبها مرئية للمستخدمين من خلال التلاعب بـ DOM. مثل عملية تطوير الصور في غرفة مظلمة، نحن نحول البيانات غير المرئية إلى شيء يمكن للمستخدمين رؤيته والتفاعل معه. التعامل مع DOM هو التقنية التي تحول صفحات الويب الثابتة إلى تطبيقات ديناميكية تقوم بتحديث محتواها بناءً على تفاعلات المستخدم واستجابات الخادم.

اختيار الأداة المناسبة للعمل

عندما يتعلق الأمر بتحديث HTML باستخدام JavaScript، لديك عدة خيارات. فكر في هذه الخيارات كأدوات مختلفة في صندوق الأدوات - كل واحدة مثالية لمهام معينة:

الطريقة الآمنة لعرض النص: textContent

خاصية textContent هي أفضل صديق لك عند عرض بيانات المستخدم. إنها مثل الحارس الشخصي لصفحتك على الويب - لا شيء ضار يمكن أن يمر: فوائد textContent: - تعامل كل شيء كنص عادي (تمنع تنفيذ السكربتات) - تقوم بمسح المحتوى الموجود تلقائيًا - فعالة لتحديث النصوص البسيطة - توفر أمانًا مدمجًا ضد المحتوى الضار

إنشاء عناصر HTML ديناميكية

للحصول على محتوى أكثر تعقيدًا، اجمع بين document.createElement() وطريقة append(): فهم هذا النهج: - ينشئ عناصر DOM جديدة برمجيًا - يحافظ على التحكم الكامل في سمات العنصر ومحتواه - يسمح بإنشاء هياكل عناصر متداخلة ومعقدة - يحافظ على الأمان بفصل الهيكل عن المحتوى مخاطر innerHTML: - تنفذ أي علامات