أعتقد أن كل مهندس للواجهة الأمامية لديه إطار جافا سكريبت المفضل لديه، سواء كان ذلك يتعلق بالعاطفة أو المعتقد، لا يجلب إطار جافا سكريبت التطوير المريح فحسب، بل يجلب أيضًا جمالًا منطقيًا خالصًا، سواء كان ذلك من خلال بساطة jquery الرائعة أو سحر Yui. صندوق الرمل، جميعهم يمنحوننا خيالًا لا نهاية له. ومع ذلك، لا بد أن يكون إطار عمل js غير قادر على تحقيق الكمال الشامل، على سبيل المثال، فإن تنازلات jquery في OO وتضحيات yui في الأداء تنقل جميعًا نوعًا من الجمال غير الكامل والواقعية المثالية للناس. اليوم، دعونا نلقي نظرة على هذه التضحيات والتنازلات التي قدمتها yui3 في تصميم الإطار، حتى نتمكن من الحصول على فهم أعمق للصورة الكاملة لـ yui3 وتعظيم مزاياها.
1. خطوة واحدة أو تحبيب البذور
ما يسمى بالبذر بخطوة واحدة يعني أنك تحتاج فقط إلى تقديم علامة نصية لملف أولي على الصفحة، مثل النموذج الأولي وjquery، وإدخال Prototype.js أو jquery.js فقط، وسوف يقومان بتغليف عمليات DOM و الأحداث وما إلى ذلك في ملف وحاول إبقائه صغيرًا قدر الإمكان. إن فوائد القيام بذلك واضحة للغاية. ومع ذلك، قسمت Yui هذه الوظائف إلى تصميمات هرمية وحبيبية، واستخلصت من الناحية النظرية "الأساسية" و"الأدوات" و"المكونات". من الواضح أن هذا التصميم ليس سهل الاستخدام للمبتدئين مثل jquery، وهو ليس غبيًا بدرجة كافية لاستخدامه لتنفيذ وظيفة صغيرة. هناك سببان وراء قيام yui بذلك. أولاً، yui كبير جدًا، ومن غير الموثوق به بعض الشيء تجميع جميع الوظائف في ملف واحد. ثانيًا، إنه يمهد الطريق لتصميم إطار التحميل الديناميكي.
2. المقدمة اليدوية أو التحميل الديناميكي
الطريقة التقليدية لكتابة js في الصفحة هي كتابة ملف js مباشرة في الصفحة كمسار علامة البرنامج النصي. يمكنك أيضًا تقديم الصفحة بهذه الطريقة باستخدام yui، لكن yui توصي باستخدام أداة التحميل للتحميل الديناميكي. أصل البرامج النصية المحملة ديناميكيًا معقد جدًا في الوقت الحالي، هناك ثلاثة أسباب رئيسية. أولاً، ستشغل علامات js المكتوبة بخط اليد في الصفحة طلب http على أي حال لبدء طلب http حقيقي بعد تخزينه مؤقتًا، ثانيًا، يمكن للتحميل الديناميكي أن يحقق التحميل عند الطلب، ويمكن إلغاء التكرار والفرز وفقًا للتبعيات بين ملفات js. يتطلب تحميل ملفات js بعلامات مكتوبة بخط اليد من المطورين إيلاء المزيد من الاهتمام فرز الملفات ونسخها وما إلى ذلك. ثالثًا، يؤدي التحميل الديناميكي إلى دلالات رمز الصفحة، مما يسمح للمطورين بالاهتمام فقط بـ "ما هو مطلوب" دون القلق بشأن "كيفية الحصول عليه". عندما تصبح المشاريع أكثر تضخماً وتصبح تكاليف الصيانة أعلى فأعلى، فإن هذه التقنيات الصغيرة والمتوسطة الحجم ستكون ذات فائدة كبيرة.
3. مدخل واحد أو صندوق رمل لبدء التشغيل المنطقي
عندما نبدأ منطق js في صفحة ما، فإننا عادةً ما نضعه بطريقة مثل onDomReady. ماذا لو كان هناك منطقات متعددة في الصفحة؟ على سبيل المثال، منطق التنفيذ A، ورمز الصفحة يشبه هذا
<script src="logicA.js" />
<النص البرمجي>
$.onDomReady(function(){
___LogicA.start();
});
</script>
عادةً ما يتم كتابة هذا الرمز في نهاية الصفحة، ويتم دفن كود html المصاحب لهذا المنطق في مكان ما على الصفحة. في هذا الوقت، يحتاج b إلى إضافة المنطق B إلى الصفحة النهاية، ثم قم بتغييرها لتبدو هكذا:
<script src="logicA.js" />
<script src="logicB.js" />
<النص البرمجي>
$.onDomReady(function(){
___LogicA.start();
___LogicB.start();
});
</script>
وبالمثل، فإن كود html المصاحب لمنطق B مدفون أيضًا في مكان ما على الصفحة. ويبدو أن منطق js ورمز html المصاحب له منفصلان جدًا لدرجة أنه عندما يتعلق الأمر بحذف الوظيفة، فغالبًا ما يتم حذف html ولكن يتم نسيان js. . أو حذف js ونسيان حذف html سيؤدي أيضًا إلى حدوث مشكلات عند إعادة استخدام التعليمات البرمجية. وبالمثل، عند تصحيح الأخطاء، يجب على المهندسين فتح نافذتين والتركيز على js وhtml على التوالي، حتى لو كان قطعتي التعليمات البرمجية في نفس الملف. في هذه الحالة من الأفضل كتابة الكود كالتالي:
طريقة الترميز هذه هي بالضبط ما يدعو إليه Yui، وهو ما يسمى بـ Sandbox. كل منطق موجود في Sandbox، وكل منها يقوم بعمله الخاص دون التدخل في بعضها البعض. عندما يتصفح طرف ثالث الكود، يفهم على الفور أن هذه كتلة وظيفية مستقلة، بما في ذلك بنية HTML النموذجية ومنطق بدء التشغيل js. إذا أرادوا إعادة الاستخدام، يمكنهم فقط نسخ الكتلة بأكملها.
<!–مقتطف كود html منطقي–>
<script src="logicA.js" />
<النص البرمجي>
$.onDomReady(function(){
___LogicA.start();
});
</script>
…
<!–B مقتطف كود HTML المنطقي–>
<script src="logicB.js" />
<النص البرمجي>
$.onDomReady(function(){
___LogicB.start();
});
</script>