في عملية تطوير برامج AJAX، يرتكب العديد من الأشخاص بعض الأخطاء الشائعة، وقد تؤدي بعض الأخطاء إلى تعريض وظائف وأداء برنامج AJAX للخطر، مما يؤدي إلى ضياع جميع مزايا برنامج AJAX. هنا سيقدم لك المؤلف الخطايا السبع المميتة التي يجب عليك الانتباه إليها عند تطوير برامج AJAX.
يعد AJAX أمرًا جيدًا، فهو يسمح للمطورين ببناء تطبيقات أكثر ديناميكية بشكل أسرع وأكثر كفاءة. ولكن لديها أيضا عيوبها الخاصة.
للوهلة الأولى، قد يبدو أن القليل من المنطق السليم من شأنه أن يمنع هذه المزالق، وإلى حد ما، فإنه يفعل ذلك. ولكن بالمقارنة مع منافسه DHTML، فإن بنية برنامج AJAX مختلفة تمامًا. بغض النظر عن مقدار الفطرة السليمة التي تتمتع بها في جهود تطوير التطبيقات، يجب أن تتعلم من دروس من سبقوك. في هذه المقالة، نشير إلى هذه الأخطاء باسم "الخطايا السبع المميتة"، ولكنها لا تمثل جميع الأخطاء.
قبل أن نتعرف على الأخطاء السبعة القاتلة في تطوير AJAX، دعونا نلقي نظرة على سبعة أخطاء أقل خطورة. الجميع يرتكب هذه الأخطاء. قم بإجراء بحث على Google وسترى مدى شيوع هذه الأخطاء.
سبع جنح
1. إساءة استخدام زر الرجوع - يرتكب العديد من الأشخاص هذا الخطأ، وقد أصبح زر الرجوع ضروريًا في العديد من برامج تجربة الويب. يضيف العديد من مطوري AJAX المبتدئين زر الرجوع إلى برامج AJAX الخاصة بهم لأسباب مختلفة، لكنهم يجدون أن زر الرجوع يؤثر على وظائف البرنامج. ويرجع ذلك أساسًا إلى أن Javascript ليست لغة برمجة سهلة الاستخدام للغاية. ثانيًا، يتعين على المطورين إعادة تعلم أفكار تطوير AJAX.
بالنسبة لأولئك الجدد في AJAX، ليس من السهل قبول فكرة أن زر الرجوع ليس حلاً جيدًا. عندما نكون في نقطة تحديث الصفحة، أو عندما نحتاج إلى استخدام وظيفة "التراجع"، يمكننا التفكير في "مفتاح الرجوع". ولكن يجب عليك التفكير مرتين قبل البرمجة، وإلا فسيتم إجراء تحديثات متكررة بسهولة.
2. عدم إبلاغ المستخدم بنتائج العملية - جزء من كيفية عمل AJAX هو أنه لا يستخدم أداة تحميل واجهة مستخدم الويب المعتادة. لذلك، تحتاج إلى تصميم بعض الإشارات المرئية حتى يتمكن المستخدمون من فهم ما يحدث.
3. الروابط التي تم التغاضي عنها - يعد هذا أيضًا خطأ قياسي في AJAX: ترك رابط URL الذي يمكن للمستخدمين الخارجيين قصه ولصقه. لقد قمنا جميعًا بنسخ عنوان URL وإرساله إلى شخص آخر. عندما نستخدم AJAX، لا يمكننا توفير الروابط للآخرين إلا من خلال الإدخال اليدوي فقط. لماذا؟ لأنه في تطبيقات AJAX، لا يوفر الخادم هذه الصفحة التي يتم إنشاؤها تلقائيًا في Javascript. لا تتجاهل هذه الميزة الأكثر شيوعًا في تطبيقات الويب والتي قد يهتم بها المستخدمون. يرجى تخصيص بعض الوقت لتزويد المستخدم بعنوان URL، حيث أن الخادم لا يوفر واحدًا.
4. استخدم التحكم في المحتوى بدلاً من التحكم في الصفحة - إذا كنت تبحث عن التحكم الديناميكي في المحتوى، فإن اختراق تطبيق AJAX في طريقة التفاعل التقليدية بين العميل والخادم يمكن أن يكون هدية عظيمة لك. ومع ذلك، فإن لهذا أيضًا عيوبه الخاصة: على الرغم من أنك تتمتع بقدر كبير من التحكم في إعادة كتابة المحتوى في موقع محدد على الصفحة لضبط تجربة تفاعل المستخدم، فقد ينتهي بك الأمر بصفحة غير مكتملة.
في كثير من الحالات، نركز على معالجة جزء معين من الصفحة وننسى أن الخادم لن يقوم بتحديث الصفحة. يمكن أن يؤدي ذلك إلى صفحات مزدحمة وتجربة سيئة للمستخدم: عندما يشاهدون الصفحة، قد ينظرون إلى صفحة قديمة. يرجى مراقبة الصفحة بأكملها والتأكد من تحديث أي صفحة ذات محتوى ديناميكي.
5. العناكب المتعبة - تكمن ميزة AJAX في الكمية الكبيرة من النص التي يمكن توفيرها للصفحة دون إعادة التثبيت؛ كما يكمن عيب AJAX في الكمية الكبيرة من النص التي يمكن توفيرها للصفحة دون إعادة التثبيت. إذا تم تصميم التطبيق ليكون صديقًا لمحركات البحث، فيجب أن تكون قادرًا على تخيل ما يمكن أن يحدث. بغض النظر عما يحدث في الصفحة، تأكد من وضع الكثير من النصوص الصلبة في الأعلى ودع العناكب تستمتع بوقتها.
6. الأحرف المشوهة - لا يمكن لـ AJAX دعم مجموعات أحرف متعددة. هذا ليس حدًا للحياة أو الموت، لكن نسيان ذلك يمكن أن يؤدي إلى مشاكل حقيقية. مجموعة الأحرف الأساسية هي UTF-8. بغض النظر عن مجموعة الأحرف التي يرسلها جافا سكريبت، لا تنس تشفيرها بشكل صحيح وتعيين مجموعة الأحرف من جانب الخادم بناءً على المحتوى.
7. لا يتم تقديم أي مطالبات للمستخدمين الذين لا يدعمون Javascript - بعض المتصفحات لا تدعم Javascript، ولا يستطيع هؤلاء المستخدمون فهم ما يحدث. يرجى منحهم بعض النصائح.
ما ورد أعلاه هو بعض الأخطاء التي يسهل العثور عليها. يتم التغاضي بسهولة عن المشاكل الحقيقية.
سبع خطايا مميتة
1. السماح للذاكرة بالفيضان - أي شخص شارك في أعمال التطوير لفترة طويلة يعرف ما هي المراجع الدائرية ويفهم الضرر الذي تسببه المراجع الدائرية لإدارة الذاكرة. Javascript المستخدمة بواسطة AJAX هي لغة إدارة الذاكرة. بمعنى آخر، تحتوي Javascript على وظيفة تجميع حزم مضمنة، بحيث يمكنها استخراج المتغيرات التي لم تعد مستخدمة بواسطة المسارات المرجعية وإعادة تخصيص الذاكرة التي تستخدمها هذه المتغيرات.
أي شخص يعمل في مجال التطوير لفترة طويلة يعرف ما هي المراجع الدائرية ويفهم المخاطر التي تجلبها لإدارة الذاكرة. Javascript المستخدمة بواسطة AJAX هي لغة إدارة الذاكرة. بمعنى آخر، تحتوي Javascript على وظيفة تجميع حزم مضمنة، بحيث يمكنها استخراج المتغيرات التي لم تعد مستخدمة بواسطة المسارات المرجعية وإعادة تخصيص الذاكرة التي تستخدمها هذه المتغيرات.
الآن، هنا تأتي المشكلة: في نموذج كائن الملف، قد تتم الإشارة إلى أي عقدة DOM في شجرة الملفات بواسطة عناصر أخرى موجودة في الشجرة، بغض النظر عما إذا كان قد تمت الإشارة إليها بواسطة كائنات أخرى! لذلك، أي كائن تم وضع علامة عليه في مجمع الحزم كمرجع مرة أخرى بواسطة عقدة DOM يجب أن يكون صفرًا في هذا الاتجاه، وإلا ستظل ذاكرته مخصصة.
2. لا تفهم معنى كلمة "غير متزامن" - كلمة غير متزامنة يمكن أن تجعل المستخدمين غير المعتادين عليها يشعرون بالتوتر بسهولة. ولكن إذا كان تطبيق الويب الذي تصممه لهؤلاء المستخدمين هو تطبيق سطح مكتب، فلن ينزعجوا. هذه نقطة تصميم حاسمة. تعمل معظم تطبيقات الويب بشكل مشابه جدًا لنظيراتها على سطح المكتب. لكن في تطبيقات الويب، يتوقع المستخدمون أن تؤدي هذه الجودة الوهمية إلى أن يصبحوا مختلفين تمامًا.
لدى المستخدمين تحيزات وتوقعات مختلفة تمامًا عند التعامل مع متصفحات الويب مقارنة بتطبيقات سطح المكتب. لذلك، في حين أن الاستجابات المتكررة بين الصفحة والخادم ستكون لطيفة وفعالة، مع قيام الصفحة بمراجعة نفسها في وقت واحد، فإنها ستجعل المستخدم يشعر بالدوار. لذلك، عليك اتباع قاعدتين ومراعاة كل تغيير يأتي في النطاق البصري للمستخدم: إذا لم يكن التحديث عاجلاً للمستخدم، فاجعل الترقية لطيفة وليس نقلًا؛ وإذا لم يكن التحديث عاجلاً للمستخدم، فإن التفاعل مع التطبيق مهم جداً، لذا يجب أن تكون التحديثات واضحة وواضحة.
3. جعل الخادم أعمى - يعد تقليل الاتصال بين العميل والخادم مشكلة كبيرة، وهو ما لم يكن هو الحال من قبل. في الماضي، كان التطبيق من جانب الخادم يعرف كل شيء ويمكنه رؤية كل شيء: كل استثناء، وكل إعادة تحميل، وكل حدث يمكن رؤيته وتسجيله، وبالطبع يعرف الخادم أيضًا ما يحدث على العميل، لأن الخادم ما يتم عرضه سيتم تسجيلها على الشاشة.
هذا ليس هو الحال في تطبيقات AJAX. عند وقوع الأحداث، تكون هذه الأحداث مستقلة عن الخادم، أي أنه عندما تكون هناك مشكلة على العميل، فإن الخادم لا يعرفها على الفور. اكتشاف وتسجيل الأحداث والاستثناءات من جانب العميل في موقع يمكّن الخادم من تعقب المشكلات التي تتطلب التدخل.
4. استخدم GET لتكون كسولًا - وظيفة GET هي استرداد البيانات؛ ووظيفة POST هي إعداد GET. لا تستخدم GET بشكل غير لائق، ولا تجربه حتى إذا كنت تعتقد أنه غير ضار. تؤدي إجراءات GET إلى تغيير الحالة، وقد تؤدي الروابط التي تغير الحالة إلى إرباك المستخدمين؛ ويعتقد معظمهم أن الروابط مخصصة للتنقل وليس للوظيفة.
5. لا توجد مراقبة لأنواع البيانات - جافا سكريبت ليست جزءًا من إطار عمل .NET. على الرغم من أن هذا أمر محزن بعض الشيء، إلا أنه يوضح مشكلة قد نواجهها: التأكد من أن Javascript يفهم أنواع البيانات الموجودة على النظام الأساسي الذي يعمل عليه، والعكس صحيح بالنسبة لـ .NET أو غيره. قد تكون هناك تحويلات متعددة ويتعين عليك إجراؤها واحدة تلو الأخرى. على سبيل المثال، توفر مكتبة Ajax.NET Pro محولات تقوم بتحويل تدوينات كائنات .NET وJavascript.
6. لا يمكن إغلاق بعض البرامج - سيكون إنشاء المحتوى ديناميكيًا دون تحديث الصفحة أمرًا سيئًا للغاية إذا لم يكن هناك وقت للإغلاق. كم عدد صفحات الويب التي تحتوي على ما عدد صفحات الويب التي رأيتها والتي تكون أطول من هانسارد عضو الكونجرس؟ إذا امتدت صفحة الويب إلى أجل غير مسمى، فستكون بلا شك كابوسًا للمستخدمين. فقط فكر في ما سيفكر به المستخدمون في التطبيقات التي لا تتوقف أبدًا. اجعل تطبيق الويب الخاص بك ديناميكيًا، ولكن ضمن حدود ما هو ممكن.
7. اجعل Javascript وDOM مستقلين عن بعضهما البعض - تذكر أن AJAX يعتمد على بنية "Model-View-Controller" (Model-View-Controller)، يرجى أخذ هذا على محمل الجد. ينتمي جافا سكريبت إلى الطبقة النموذجية، وينتمي DOM إلى الطبقة المرئية، ووحدة التحكم هي مستشار الزواج الذي يربطهما. تأكد من أن ملفات الويب الخاصة بك مستقلة عن Javascript (بحيث تكون أكثر فائدة للمستخدمين الذين لا يدعمون Javascript) - إلا إذا كان المحتوى نفسه ذا معنى فقط للمستخدمين الذين يستخدمون Javascript. في هذه الحالة، استخدم Javascript لإنشاء المحتوى