كيفية جعل برامج الواجهة الأمامية على شبكة الإنترنت هي مشكلة سأدرسها دون وعي في كل مرة أقوم فيها بتطوير الواجهة الأمامية. قبل بضع سنوات ، نشر المهندسون الأماميون الرائعون في Yahoo كتابًا حول تحسين أداء الواجهة الأمامية على شبكة الإنترنت ، والذي تسبب في إحساس في صناعة تكنولوجيا تطوير الويب بأكملها ، مما يجعل سؤال الأمامي الغامض على شبكة الإنترنت ، وهو ملفوف في الشارع ، وأصبح التحسين الأمامي على الويب سؤالًا بسيطًا يمكن لكل من المبتدئين والعروض الكبرى الرد. عندما تعرف الصناعة بأكملها الإجابة على السر المفاجئ ، لم تعد تقنية التحسين الحالية تنتج قفزة نوعية لموقع الويب الذي تطوره. من أجل جعل أداء موقع الويب الذي نطوره بشكل أفضل من مواقع الويب الأخرى ، نحتاج إلى التفكير بعمق وحجز مهارات أفضل.
نظام الأحداث في JavaScript هو أول نقطة اختراق أفكر فيها. لماذا هو نظام أحداث JavaScript؟ نعلم جميعًا أن الواجهة الأمامية على الويب تحتوي على ثلاث تقنيات: HTML و CSS و JavaScript. من الواضح كيف يتم الجمع بين HTML و CSS: النمط والفئة والمعرف و HTML. لا يوجد شيء يمكن الحديث عنه ، ولكن كيف تدخل JavaScript إلى الوسط بين HTML و CSS وتتيح للتكامل الثلاثة؟ أخيرًا ، وجدت أن نقطة الدخول هذه هي نظام الأحداث في JavaScript. بغض النظر عن المدة أو رمز JavaScript المعقد الذي نكتبه ، فإنه ينعكس في النهاية في HTML و CSS من خلال نظام الحدث. لذلك ، كنت أفكر أنه نظرًا لأن نظام الأحداث هو نقطة الدخول لدمج الثلاثة ، فسيكون هناك حتماً عدد كبير من عمليات الأحداث في صفحة ، خاصة في صفحات الويب المعقدة اليوم. بدون هذه الأحداث ، لا يمكن استخدام رمز JavaScript الذي كتبناه بعناية إلا في المكتبة ، والأبطال عديمة الفائدة. نظرًا لوجود عدد كبير من وظائف الأحداث على الصفحة ، هل ستكون هناك مشاكل تؤثر على الكفاءة عند كتابة وظائف الحدث كما اعتدنا؟ الإجابة التي درستها هي أنها مشكلة حقيقية في الكفاءة ، وهي أيضًا مشكلة خطيرة في الكفاءة.
لتوضيح إجابتي ، أريد أن أشرح نظام الأحداث في JavaScript بالتفصيل.
نظام الأحداث هو نقطة الدخول لانصهار JavaScript و HTML و CSS. هذه النقطة تشبه الوظيفة الرئيسية في جافا. كل السحر يبدأ هنا. فكيف يكمل المتصفح هذا الإدخال؟ لقد درست ثلاث طرق ، هم:
الطريقة 1: معالجة الأحداث HTML
معالجة الأحداث HTML هي كتابة وظائف الحدث مباشرة في علامة HTML. نظرًا لأن طريقة الكتابة هذه مقترنة بشكل وثيق بعلامة HTML ، فهي تسمى معالجة الأحداث HTML. على سبيل المثال ، الكود التالي:
نسخة الكود كما يلي:
<type type = "button" id = "btn" name = "btn" onClick = "Alert ('Click Me!')"/>
إذا كانت وظيفة حدث النقر معقدة ، فإن كتابة كود مثل هذا سيؤدي بالتأكيد إلى إزعاج. لذلك ، غالبًا ما نكتب الوظيفة في الخارج واتصل بشكل مباشر باسم الوظيفة ، على سبيل المثال:
نسخة الكود كما يلي:
<type type = "button" id = "btn" name = "btn" onClick = "btnclk ()"/>
وظيفة btnclk () {
تنبيه ("انقر لي!") ؛
}
طريقة الكتابة أعلاه هي طريقة كتابة جميلة للغاية ، بحيث يستخدمها الكثير من الناس دون وعي في الوقت الحاضر ، ولكن قد لا يعرف الكثير من الناس أن طريقة الكتابة الأخيرة ليست قوية مثل طريقة الكتابة السابقة. هذه أيضًا مشكلة واجهتها عند دراسة تقنية البرنامج النصي غير المحظورة منذ وقت ليس ببعيد ، لأنه وفقًا لمبدأ التحسين الأمامي ، غالبًا ما يكون رمز JavaScript في أسفل الصفحة. عندما يتم حظر الصفحة بواسطة برنامج نصي ، قد لا يتم تنفيذ الوظيفة المشار إليها في علامة HTML بعد. في هذا الوقت ، ننقر على زر الصفحة ، وسيتم الإبلاغ عن النتيجة "وظيفة XXX هي خطأ غير محدد". في JavaScript ، سيتم اكتشاف مثل هذه الأخطاء من خلال المحاولة. لذلك ، من أجل جعل الكود أكثر قوة ، سيكون لدينا إعادة كتابة:
نسخة الكود كما يلي:
<type type = "button" id = "btn" name = "btn" onClick = "Try {btnclk () ؛} catch (e) {}"/>
رؤية الكود أعلاه ليس شيئًا يمكن وصفه من قبل شخص مثير للاشمئزاز.
الطريقة 2: معالجة أحداث مستوى DOM0
معالجة الأحداث على مستوى DOM0 هي معالجة الأحداث التي تدعمها جميع المتصفحات اليوم. لا توجد مشكلة توافق. إن رؤية مثل هذه الجملة ستجعل كل من يقوم بوجود واجهة أمامية متحمسة. قاعدة معالجة الأحداث DOM0 هي: كل عنصر DOM له سمة معالجة الأحداث الخاصة به ، والتي يمكن تعيين وظيفة ، مثل الرمز التالي:
نسخة الكود كما يلي:
var btndom = document.getElementById ("btn") ؛
btndom.onclick = function () {
تنبيه ("انقر لي!") ؛
}
يتم تعريف سمات الحدث التي يتم التعامل معها بواسطة أحداث مستوى DOM0 في شكل "ON+Event Name" ، والسمات بأكملها في أحرف صغيرة. نعلم أن عنصر DOM هو كائن JavaScript في رمز JavaScript ، لذلك من السهل جدًا فهم معالجة الأحداث على مستوى DOM0 من منظور كائن JavaScript ، على سبيل المثال ، الرمز التالي:
نسخة الكود كما يلي:
btndom.onclick = null ؛
ثم يتم إلغاء حدث النقر فوق الزر.
دعونا نلقي نظرة على الكود التالي:
نسخة الكود كما يلي:
btndom.onclick = function () {
تنبيه ("انقر لي!") ؛
}
btndom.onclick = function () {
تنبيه ("انقر me1111!") ؛
}
ستؤدي الوظيفة التالية إلى الكتابة فوق الوظيفة الأولى.
الطريقة 3: معالجة الأحداث DOM2 ومعالجة الأحداث IE
معالجة الأحداث DOM2 هي حل موحد معالجة الأحداث ، ولكن متصفح IE قد طور مجموعة من الوظائف والوظائف مماثلة لمعالجة الأحداث DOM2 ، ولكن الكود يختلف عن ذلك.
قبل شرح الطريقة الثالثة ، يجب أن أضيف بعض المفاهيم ، وإلا فلن أتمكن من شرح دلالة الطريقة الثالثة.
المفهوم الأول هو: تدفق الحدث
في تطوير الصفحة ، غالبًا ما نواجه هذا الموقف. يمكن تمثيل فاصل العمل في الصفحة بواسطة مستند في JavaScript. هناك div على الصفحة. Div يعادل تراكب عنصر الوثيقة. هناك عنصر زر في Div. يقوم عنصر الزر بتراكب DIV ، وهو ما يعادل أيضًا تراكب المستند. وبالتالي فإن المشكلة هي ، عندما ننقر فوق هذا الزر ، لا يحدث سلوك النقر هذا في الواقع على الزر فقط. يتم استخدام كل من Div والمستند لعمليات النقر. وفقًا للمنطق ، يمكن أن تؤدي هذه العناصر الثلاثة إلى تشغيل أحداث النقر. يصف دفق الحدث مفهوم السيناريو أعلاه. يعني دفق الحدث: ترتيب الأحداث المستلمة من الصفحة.
المفهوم الثاني: فقاعات الأحداث والتقاط الأحداث
فقاعات الأحداث هي الحل الذي اقترحه Microsoft لحل مشكلة تدفق الحدث ، في حين أن التقاط الأحداث هو حل تدفق الحدث الذي اقترحته Netscape. مبادئهم هي كما يلي:
يبدأ الحدث الفقاعي بـ Div ، يليه جسم ، وأخيراً وثيقة ، ويتم عكس التقاط الحدث ، أولا وثيقة ، تليها جسم ، وأخيراً عنصر مستهدف. في المقابل ، يعد حل Microsoft أكثر إنسانية ويتماشى مع عادات تشغيل الأشخاص ، فإن حل Netscape محرج للغاية. هذه هي نتيجة حرب المتصفح. Netscape أبطأ ويحل مشكلة تدفق الحدث عن طريق التضحية بالرمز الذي يستخدمه المستخدمون.
صممت Microsoft نظام أحداث جديد بالاقتران مع أحداث الفقاعات ، والتي تُعرف بشكل شائع باسم معالجة الأحداث IE في الصناعة. طريقة معالجة الأحداث IE كما هو موضح في الكود التالي:
نسخة الكود كما يلي:
var btndom = document.getElementById ("btn") ؛
btndom.attachevent ("onclick" ، function () {
تنبيه ("انقر لي!") ؛
}) ؛
أضف الأحداث من خلال طريقة المرفقات لعنصر DOM تحت IE. بالمقارنة مع معالجة الأحداث DOM0 ، تغيرت طريقة إضافة الأحداث من السمات إلى الأساليب ، لذلك عندما نضيف أحداثًا ، نحتاج إلى نقل المعلمات إلى الطريقة. تتلقى طريقة المرفقات معلمتين. المعلمة الأولى هي نوع الحدث. تسمية نوع الحدث هي نفسها التي تسمية الحدث في معالجة الأحداث DOM0. المعلمة الثانية هي وظيفة الحدث. ميزة استخدام الطريقة هي أنه إذا قمنا بإضافة حدث نقرة إلى نفس العنصر ، كما هو موضح أدناه:
نسخة الكود كما يلي:
btndom.attachevent ("onclick" ، function () {
تنبيه ("انقر لي!") ؛
}) ؛
btndom.attachevent ("onclick" ، function () {
تنبيه ("انقر لي أيضًا!") ؛
}) ؛
قم بتشغيله ، يطفو كل من مربعات الحوار بشكل طبيعي ، مما يتيح لنا إضافة أحداث نقرة مختلفة متعددة إلى عنصر DOM. ماذا لو كنا نريد حدثًا؟ ماذا يجب أن نفعل؟ أقدم طريقة detachevent لحذف الأحداث. قائمة المعلمات هي نفس الملحق. إذا أردنا حذف حدث نقرة معينة ، فما عليك سوى تمرير نفس المعلمات مثل حدث إضافة ، كما هو موضح في الكود التالي:
نسخة الكود كما يلي:
btndom.detachevent ("onclick" ، function () {
تنبيه ("انقر لي أيضًا!") ؛
}) ؛
عند تشغيله ، تكون العواقب خطيرة للغاية ونشعر بالارتباك. لم يتم حذف النقر الثاني. ماذا يحدث هنا؟ ذكرت سابقًا أن حذف الأحداث يتطلب تمرير معلمات مثل إضافة الأحداث. ومع ذلك ، في الوظيفة المجهولة لجافا سكريبت ، حتى لو كانت رمز الوظيفين المجهولين هو نفسه تمامًا ، فستستخدم JavaScript متغيرات مختلفة لتخزينها داخليًا. نتيجةً لذلك ، لا يمكن للظاهرة التي نراها أن تحذف حدث النقر ، لذلك يجب كتابة الكود لدينا مثل هذا:
نسخة الكود كما يلي:
var ftn = function () {
تنبيه ("انقر لي أيضًا!") ؛
} ؛
btndom.attachevent ("onclick" ، ftn) ؛
btndom.detachevent ("onclick" ، ftn) ؛
تشير الطريقة التي تمت إضافتها وحذف الطريقة التي تم حذفها بهذه الطريقة إلى نفس الكائن ، وبالتالي تم حذف الحدث بنجاح. يخبرنا السيناريو هنا أننا بحاجة إلى عادة جيدة لكتابة الأحداث التي يجب أن نحددها العمليات بشكل مستقل ، وعدم استخدام وظائف مجهولة كمعتادة.
التالي هو معالجة الأحداث DOM2 ، ويظهر مبدأها في الشكل أدناه:
DOM2 هو حدث موحد. باستخدام أحداث DOM2 ، يبدأ تسليم الأحداث من طريقة الالتقاط ، أي من المستند ، ثم إلى الجسم. DIV هي نقطة وسيطة. عندما يصل الحدث إلى النقطة الوسيطة ، يكون الحدث في المرحلة المستهدفة. بعد دخول الحدث إلى المرحلة المستهدفة ، يبدأ الحدث في الانفجار والتعامل ، وأخيراً ينتهي الحدث على المستند. (أشير إلى توثيق في هذه المقالة ، لكن الموقف الفعلي هو أن بعض المتصفحات ستبدأ في التقاط الحدث وإنهاء الفقاعة في النافذة. ومع ذلك ، أعتقد أنه بغض النظر عن كيفية تعيين المتصفح نفسه أثناء التطوير ، فهو أكثر توجهاً نحو التطوير لإيلاء الاهتمام للوثائق ، لذلك أنا أستخدم المستند هنا). يتم استخدام الأشخاص لتصنيف المرحلة المستهدفة كجزء من الفقاعة ، وذلك أساسًا لأن أحداث الفقاعة تستخدم على نطاق أوسع في التطوير.
معالجة الأحداث DOM2 أمر صعب للغاية. عندما يتم تشغيل كل حدث ، سيتم اجتياز جميع العناصر مرتين. بالمقارنة مع حدث IE ، فإن الأداء أسوأ بكثير من حدث IE. أنا فقط أتعامل مع الفقاعات ، لذلك أنا فقط بحاجة إلى اجتياز مرة واحدة. ومع ذلك ، لا يعني أقل اجتياز أن نظام الأحداث IE أكثر كفاءة. إن دعم نظامين الأحداث في نفس الوقت سيؤدي إلى مرونة أكبر لتطويرنا من منظور التطوير والتصميم. من هذا المنظور ، لا تزال أحداث DOM2 مرغوبة للغاية. رمز حدث DOM2 كما يلي:
نسخة الكود كما يلي:
var btndom = document.getElementById ("btn") ؛
btndom.addeventListener ("Click" ، function () {
تنبيه ("انقر لي!") ؛
}،خطأ شنيع)؛
var ftn = function () {
تنبيه ("انقر لي أيضًا!") ؛
} ؛
btndom.addeventListener ("Click" ، ftn ، false) ؛
تستخدم إضافة الأحداث في معالجة الأحداث DOM2 AddEventListener ، والتي تتلقى معلمة أخرى أكثر من معالجة الأحداث IE. الأولان يعنيان نفس المعلمتين لطريقة معالجة الأحداث IE. الفرق الوحيد هو أن البادئة على المعلمة الأولى ، والمعلمة الثالثة هي قيمة منطقية. إذا كانت قيمتها صحيحة ، فسيتم معالجة الحدث في وضع الالتقاط ، مع القيمة الخاطئة. تتم معالجة الحدث في الفقاعات. مع المعلمة الثالثة ، يمكننا أن نفهم سبب قيام عنصر الحدث بتشغيل مرتين في معالجة الأحداث DOM2. والغرض من ذلك هو أن تكون متوافقة مع نماذج الحدث. ومع ذلك ، يرجى ملاحظة هنا أنه بغض النظر عما إذا كنا نختار التقاط أو الفقاعة ، سيتم تنفيذ اجتياز الاثنين إلى الأبد. إذا اخترنا طريقة واحدة لمعالجة الأحداث ، فلن يتم تشغيل أي وظيفة معالجة الأحداث في عملية معالجة الأحداث الأخرى. هذا هو نفس مبدأ خلط السيارة في العتاد المحايد. من خلال تصميم طريقة حدث DOM2 ، نعلم أن أحداث DOM2 يمكنها تنفيذ واحدة فقط من طريقتين لمعالجة الأحداث في وقت التشغيل. من المستحيل أن يثير نظامان لدفق الأحداث في نفس الوقت. لذلك ، على الرغم من أن العنصر يتم اجتيازه مرتين ، إلا أنه لا يمكن استفزاز وظيفة الحدث مرتين. لاحظ أنني أقصد أنه لا يتم استفزاز مرتين ، وهو ما يشير إلى وظيفة الحدث. في الواقع ، يمكننا محاكاة الموقف الذي يتم فيه تنفيذ نموذجين لدفق الأحداث في نفس الوقت ، مثل الرمز التالي:
نسخة الكود كما يلي:
btndom.addeventListener ("Click" ، ftn ، true) ؛
btndom.addeventListener ("Click" ، ftn ، false) ؛
لكن طريقة الكتابة هذه هي معالجة متعددة الأحداث ، والتي تعادل النقر فوق الزر مرتين.
يوفر DOM2 أيضًا وظيفة لحذف الأحداث. هذه الوظيفة هي إزالة exmenteventListener ، مكتوب على النحو التالي:
نسخة الكود كما يلي:
btndom.removeeventListener ("Click" ، ftn ، false) ؛
وينطبق الشيء نفسه على حدث IE ، أي أن المعلمات يجب أن تكون متسقة مع المعلمات التي تحدد الحدث. ومع ذلك ، عند استخدام RemoveEventListener ، لم يتم تمرير المعلمة الثالثة. الافتراضي هو حذف حدث الفقاعة ، لأن الافتراضي خاطئ إذا لم يتم تمرير المعلمة الثالثة. على سبيل المثال:
نسخة الكود كما يلي:
btndom.addeventListener ("Click" ، ftn ، true) ؛
btndom.removeeventListener ("Click" ، ftn) ؛
قم بتشغيله واكتشف أنه لم يتم حذف الحدث بنجاح.
أخيرًا ، أود أن أقول إن معالجة أحداث DOM2 مدعومة جيدًا في IE9 ، بما في ذلك IE9 أو أعلاه ، ولا يدعم IE8 أدناه أحداث DOM2.
دعنا نقارن طرق الحدث الثلاثة أدناه ، على النحو التالي:
المقارنة 1: مقارنة بين طريقة واحدة لجانب واحد والطريقتين الأخريين
طريقة كتابة الطريقة الأولى هي الجمع بين HTML و JavaScript. لديك لي ولديك. تعميق هذه الطريقة لتحقيق تطور مختلط من HTML و JavaScript. في مصطلح البرنامج ، هو اقتران رمز. اقتران الكود ليس جيدًا ، وهو سيء للغاية. هذا هو مستوى مبرمج الصاعد ، لذلك بمجرد هزيمة الطريقة تمامًا ، سيفوز الطريقتان الآخرتان.
المقارنة 2: الطريقة 2 والطريقة 3
واثنان منهم مكتوبون بنفس الطريقة. في بعض الأحيان يكون من الصعب حقًا تحديد من هو أفضل أو أسوأ. بالنظر إلى المحتوى أعلاه ، وجدنا أن الفرق الأكبر بين الوضع 2 والوضع 3 هو أن هناك حدثًا واحدًا فقط في عنصر DOM ، وفقط مرة واحدة فقط ، في حين أن الوضع 3 يمكن أن يسمح بحدث في عنصر DOM أن يكون له وظائف معالجة الأحداث المتعددة. في معالجة الأحداث DOM2 ، يمكن أن يسمح لنا الوضع 3 أيضًا بالتحكم بدقة في طريقة تدفق الحدث. لذلك ، فإن وظيفة الوضع 3 أقوى من الوضع 2 ، لذلك مقارنة مع الوضع 3 ، فهي أفضل قليلاً.
فيما يلي محور هذه المقالة: مشاكل أداء أنظمة الأحداث. لحل مشاكل الأداء ، يجب على المرء أن يجد التركيز. هنا سأفكر في مشكلات أداء أنظمة الأحداث من نقطتين تركيز ، وهما: تقليل عدد الترافاز واستهلاك الذاكرة.
بادئ ذي بدء ، عدد troversals. سواء أكان ذلك يلتقط تدفقات الأحداث أو تدفقات الأحداث الفقاعية ، فسوف يعبرون العناصر ، لكنهم سيبدأون جميعهم من النافذة أو المستند العلوي. إذا كان لعنصر DOM في الصفحة علاقة عميقة الوالدين والطفل ، فكلما زاد عدد العناصر التي تجعلك أكثر ضررًا ، سيكون ذلك ، مثل معالجة الأحداث DOM2 ، أكبر. كيف تحل مشكلة اجتياز دفق الحدث هذا؟ جوابي لا. قد يكون لدى بعض الأصدقاء هنا أسئلة ، كيف لم يعد هناك؟ يوجد كائن حدث في نظام الأحداث ، وهو حدث. هذا الكائن لديه طريقة لمنع الأحداث الفقاعية أو التقاط. لماذا أقول أنه لا يوجد أحد؟ سؤال هذا الصديق أمر منطقي ، ولكن إذا أردنا استخدام هذه الطريقة لتقليل اجتيازنا ، فسوف يتعامل رمزنا مع العلاقة بين عناصر الأب والابن وعلاقة عنصر الجد. إذا كانت عناصر الصفحة متداخلة كثيرًا ، فهذه مهمة لا يمكن إكمالها ، لذا فإن إجابتي هي أنه لا يمكن تغيير مشكلة اجتياز ، ولا يمكننا فقط التكيف معها.
يبدو أن تقليل اجتياز التجارة لا يمكن أن يحل مشكلة أداء نظام الأحداث ، لذلك يمكننا الآن التفكير في استهلاك الذاكرة فقط. غالبًا ما أسمع أن الناس يقولون إن C# مفيد للغاية ، لكنه أفضل لتطوير الواجهة الأمامية على شبكة الإنترنت. يمكننا سحب زر مباشرة إلى الصفحة في C# IDE. بعد وصول الزر إلى الصفحة ، سيقوم رمز JavaScript تلقائيًا بإضافة حدث إلى الزر. بالطبع ، وظيفة الحدث في الداخل هي وظيفة فارغة. لذلك أعتقد أنه يمكننا وضع 100 زر على الصفحة بهذه الطريقة. إذا لم ينجح رمز واحد ، فسيتم معالجة أحداث 100 زر ، وهو مريح للغاية. أخيرًا ، نضيف حدث زر معين إلى أحد الأزرار لجعل الصفحة تشغيل. هل هذه الصفحة فعالة؟ في JavaScript ، كل وظيفة هي كائن ، ويستهلك كل كائن الذاكرة ، لذلك يجب أن يستهلك رمز وظيفة الحدث 99 عديمة الفائدة هذا الكثير من ذاكرة المتصفح القيمة. بالطبع ، لن نفعل ذلك في بيئة التطوير الحقيقية ، ولكن في عصر اليوم من التطور الشهير في Ajax و Onefore صفحة واحدة ، هناك العديد من الأحداث على صفحة ويب ، مما يعني أن كل حدث له وظيفة حدث ، ولكن كل عملية نؤديها فقط. في هذا الوقت ، تنام أحداث أخرى أثناء الاستلقاء ، والتي لا تلعب أي دور وتستهلك ذاكرة الكمبيوتر.
نحتاج إلى حل لتغيير هذا الموقف ، وهناك بالفعل مثل هذا الحل في الواقع. من أجل وصف هذه الخطة بوضوح ، أريد إضافة بعض المعرفة الأساسية أولاً. في مناقشة معالجة الأحداث DOM2 ، ذكرت مفهوم الكائن المستهدف. وضع جانبا طريقة معالجة الأحداث DOM2 ، هناك أيضًا مفهوم الكائن المستهدف في معالجة الأحداث التقاط ومعالجة الأحداث الفقاعية. الكائن الهدف هو عنصر DOM في التشغيل المحدد للحدث. على سبيل المثال ، الزر الموجود في تشغيل زر النقر هو الكائن الهدف. بغض النظر عن طريقة معالجة الأحداث ، ستحتوي وظيفة الحدث على كائن حدث. يحتوي كائن الحدث على هدف سمة ، ويشير الهدف دائمًا إلى الكائن الهدف ، وله كائن الحدث سمة أخرى ، CurrentTarget ، والتي تشير إلى عنصر DOM الذي يتدفق إلى حدث الالتقاط أو الفقاعة. من الوصف أعلاه ، نعلم أنه سواء كان حدث التقاط أو حدث فقاعة ، فإن تدفق الحدث سوف يتدفق إلى المستند. إذا أضفنا حدثًا نقرة على المستند ولم يضيف الزر الموجود على الصفحة حدث نقرة ، فسنقرر الزر ونعلم أن حدث النقر على المستند سيؤدي إلى تشغيله. هناك تفاصيل هنا عندما يتم تشغيل حدث النقر على المستند ، فإن الهدف من هدف الحدث هو زر بدلاً من المستند ، حتى نتمكن من كتابة الرمز مثل هذا:
نسخة الكود كما يلي:
<type type = "button" id = "btn" name = "btn" value = "button"/>
<a href = "#" id = "aa"> aa </a>
document.adDeventListener ("Click" ، Function (EVT) {
var target = evt.target ؛
التبديل (Target.id) {
حالة "btn":
تنبيه ("زر") ؛
استراحة؛
حالة "AA":
تنبيه ("أ") ؛
استراحة؛
}
}،خطأ شنيع)؛
تشغيله ، وجدنا أن التأثير هو نفسه الحدث الذي كتبنا الزر بشكل منفصل. لكن فوائدها بديهية. تتولى إحدى الوظائف وظيفة الحدث للصفحة بأكملها ، ولا توجد وظيفة حدث في الخمول ، وهي مثالية. تحتوي هذه الخطة أيضًا على اسم مهني: تفويض الأحداث. تتم طريقة مندوب JQuery وفقًا لهذا المبدأ. في الواقع ، لا تنعكس كفاءة تفويض الأحداث فقط في تقليل وظائف الأحداث ، ولكنها تقلل أيضًا من عمليات اجتياز DOM. على سبيل المثال ، في المثال أعلاه ، نضيف وظيفة على المستند. المستند هو كائن المستوى الأعلى على الصفحة ، وكفاءة القراءة عالية جدًا. عندما يتعلق الأمر بأحداث كائن محددة ، فإننا لا نستخدم عملية DOM ولكن نستخدم السمة الهدف لكائن الحدث. كل هذا لا يمكن تلخيصه إلا في جملة واحدة: إنه سريع حقًا ، لا يوجد سبب للسرعة.
يمكن أن يجلب لنا تفويض الأحداث منتجًا ثانويًا رائعًا. يجب أن يستخدم الأصدقاء الذين استخدموا jQuery طريقة Live. ميزة الطريقة المباشرة هي أنه يمكنك إضافة عمليات الأحداث إلى عناصر الصفحة. حتى إذا لم يكن هذا العنصر موجودًا في الصفحة في الوقت الحالي ، فيمكنك إضافة أحداثه. بعد فهم آلية تفويض الحدث ، من السهل فهم مبدأ Live. في الواقع ، تتم JQuery's Live من خلال تفويض الأحداث ، كما أن Live هي أيضًا وسيلة فعالة لإضافة حدث.
بعد فهم تفويض الأحداث ، سنجد أن طريقة ربط JQuery هي طريقة غير فعالة. نظرًا لأنه يستخدم طريقة تعريف الحدث الأصلية ، يجب أن نستخدم الربط بحذر. في الواقع ، لاحظ مطورو jQuery هذه المشكلة أيضًا. الإصدار الجديد من jQuery لديه طريقة. تحتوي الطريقة On على جميع وظائف طرق Bind و Live and Elecpate. لذلك أقترح أن يتخلى الأصدقاء الذين قرأوا هذا المقال عن الطريقة السابقة لإضافة الأحداث واستخدام وظائف لإضافة الأحداث.
تفويض الحدث له ميزة أخرى. في مثال تفويض الأحداث في المقالة أعلاه ، أضفت أحداثًا إلى المستند. هنا أريد إجراء مقارنة. في jQuery ، اعتدنا على وضع تعريف أحداث عنصر DOM في الطريقة الجاهزة ، كما هو موضح أدناه:
نسخة الكود كما يلي:
$ (وثيقة). ready (function () {
xxx.bind ("Click" ، function () {}) ؛
}) ؛
يتم تنفيذ الوظيفة الجاهزة بعد تحميل مستند Page DOM. يتم تنفيذها أولاً من وظيفة Onload. هذا له العديد من الفوائد مقدما. واحدة من الفوائد هي أيضا تحسين الأداء. تعريف الحدث مثل jQuery هو أيضا ممارسة قياسية. أعتقد أن بعض الأصدقاء يجب أن يربطوا بعض الأحداث خارج جاهز ، وأخيراً أجد أن الزر سيكون غير صالح. يستغرق هذا السيناريو غير الصحيح في بعض الأحيان لحظة ، وسيكون على ما يرام بعد فترة من الوقت. لذلك ، غالبًا ما نتجاهل مبدأ هذه المشكلة ولا نربط الأحداث في الوظيفة الجاهزة. هذه العملية هي في الواقع أحداث ملزمة قبل تحميل DOM ، وفي هذه الفترة الزمنية ، نربطها فعليًا الأحداث. ، من المحتمل جدًا أن بعض العناصر لم يتم بناؤها على الصفحة ، لذلك سيكون ربط الحدث غير صالح. لذلك ، فإن سبب استعداد الأحداث هو التأكد من تحميل جميع عناصر الصفحة لتحديد أحداث عنصر DOM بعد تحميلها. ومع ذلك ، يمكن تجنب المشكلات عند استخدام مندوبي الأحداث. على سبيل المثال ، أحداث الربط إلى مستند ، يمثل المستند الصفحة بأكملها ، لذلك هو أقرب وقت لتحميله. لذلك ، من الصعب تحقيق مندوبي الأحداث على المستند ، ومن الصعب أيضًا أن يتسبب في الإبلاغ عن "وظيفة XXX غير المحددة". لتلخيص هذه الميزة: يمكن تشغيل رمز مندوب الحدث في أي مرحلة من مرحلة تحميل الصفحة ، والتي ستوفر للمطورين حرية أكبر في تحسين أداء صفحة الويب أو تعزيز تأثيرات صفحة الويب.
حسنًا ، لقد تمت كتابة هذا المقال. طاب مساؤك.