أفضل الممارسات المقبولة الشائعة حول تنظيم الرموز في JavaScript


Answers

أحاول تجنب تضمين أي javascript مع HTML. يتم تضمين كافة التعليمات البرمجية في فئات ولكل فئة في الملف الخاص به. بالنسبة إلى التطوير ، لديّ علامات <script> منفصلة لتضمين كل ملف js ، ولكن يتم دمجها في حزمة واحدة أكبر للإنتاج لتقليل الزيادة في طلبات HTTP.

عادة ، سيكون لدي ملف js "رئيسي" واحد لكل تطبيق. لذا ، إذا كنت أكتب طلبًا باستخدام "المسح" ، فستحصل على ملف js يسمى "survey.js". قد يحتوي هذا على نقطة الإدخال في رمز jQuery. أقوم بإنشاء مراجع jQuery أثناء إنشاء مثيل ثم تمريرها إلى الكائنات الخاصة بي كمعلمات. وهذا يعني أن فئات جافا سكريبت هي "خالصة" ولا تحتوي على أي مراجع لمعرفات CSS أو أسماء الفئات.

// file: survey.js
$(document).ready(function() {
  var jS = $('#surveycontainer');
  var jB = $('#dimscreencontainer');
  var d = new DimScreen({container: jB});
  var s = new Survey({container: jS, DimScreen: d});
  s.show();
});

أجد أيضًا أن اصطلاح التسمية مهم بالنسبة للقراءة. على سبيل المثال: أقوم بإرفاق "j" بكل مثيلات jQuery.

في المثال أعلاه ، هناك فئة تسمى DimScreen. (افترض أن هذا يخفي الشاشة وينبثق مربع تنبيه.) يحتاج إلى عنصر div يمكن تكبيره لتغطية الشاشة ، ثم إضافة مربع تنبيه ، لذا فأمر في كائن jQuery. لدى jQuery مفهوم مكون إضافي ، ولكن يبدو أنه مقيد (على سبيل المثال ، الحالات غير ثابتة ولا يمكن الوصول إليها) بدون أي ارتفاع حقيقي. لذا ، فإن فئة DimSCreen ستكون فئة جافا سكريبت قياسية يحدث فقط لاستخدام jQuery.

// file: dimscreen.js
function DimScreen(opts) { 
   this.jB = opts.container;
   // ...
}; // need the semi-colon for minimizing!


DimScreen.prototype.draw = function(msg) {
  var me = this;
  me.jB.addClass('fullscreen').append('<div>'+msg+'</div>');
  //...
};

لقد قمت ببناء بعض التطبيقات المعقدة نوعًا ما باستخدام هذا المنهج.

Question

نظرًا لأن إطارات جافا سكريبت مثل jQuery تجعل تطبيقات الويب من جانب العميل أكثر ثراءً وفاعلية ، فقد بدأت نلاحظ مشكلة واحدة ...

كيف تقوم بتنظيم هذا في العالم؟

  • ضع كل معالجاتك في مكان واحد واكتب وظائف لجميع الأحداث؟
  • إنشاء وظيفة / فئات لتغليف جميع وظائفك؟
  • اكتب كالمجانين ، وآمل أن يعمل على الأفضل؟
  • التخلي والحصول على مهنة جديدة؟

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

هل هناك أي توصيات عامة حول أفضل طريقة للحفاظ على ملفاتك .js لطيفة وأنيقة كبقية طلبك؟ أم أنها مجرد مسألة IDE؟ هل هناك خيار أفضل هناك؟

تصحيح

كان المقصود من هذا السؤال أن يكون أكثر حول تنظيم التعليمات البرمجية وليس تنظيم الملفات. كانت هناك بعض الأمثلة الجيدة على دمج الملفات أو تقسيم المحتوى.

سؤالي هو: ما هي طريقة أفضل الممارسات المقبولة حاليًا الشائعة لتنظيم شفرتك الفعلية؟ ما هي طريقتك ، أو حتى طريقة موصى بها للتفاعل مع عناصر الصفحة وإنشاء شفرة قابلة لإعادة الاستخدام لا تتعارض مع بعضها البعض؟

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




كسول قم بتحميل الرمز الذي تحتاجه عند الطلب. جوجل تفعل شيئا من هذا القبيل مع google.loader بهمgoogle.loader




I use a custom script inspired by Ben Nolan's behaviour (I can't find a current link to this anymore, sadly) to store most of my event handlers. These event handlers are triggered by the elements className or Id, for example. مثال:

Behaviour.register({ 
    'a.delete-post': function(element) {
        element.observe('click', function(event) { ... });
    },

    'a.anotherlink': function(element) {
        element.observe('click', function(event) { ... });
    }

});

I like to include most of my Javascript libraries on the fly, except the ones that contain global behaviour. I use Zend Framework's headScript() placeholder helper for this, but you can also use javascript to load other scripts on the fly with Ajile for example.




You can use jquery mx (used in javascriptMVC) which is a set of scripts that allows you to use models, views, and controllers. I've used it in a project and helped me create structured javascript, with minimal script sizes because of compression. This is a controller example:

$.Controller.extend('Todos',{
  ".todo mouseover" : function( el, ev ) {
   el.css("backgroundColor","red")
  },
  ".todo mouseout" : function( el, ev ) {
   el.css("backgroundColor","")
  },
  ".create click" : function() {
   this.find("ol").append("<li class='todo'>New Todo</li>"); 
  }
})

new Todos($('#todos'));

You can also use only the controller side of jquerymx if you aren't interested in the view and model parts.




قبل بضعة أيام ، WysiHat الرجال في 37Signals WysiHat ، مع تطور. قاموا بإنشاء مكتبة تقوم بتجميع ملفات javascript باستخدام نوع من أوامر ما قبل المعالج.

لقد تم استخدامها منذ ذلك الحين لفصل ملفات JS الخاصة بي ومن ثم في النهاية دمجها كواحد. وبهذه الطريقة يمكنني فصل المخاوف ، وفي النهاية ، يكون ملف واحد فقط يمر عبر الأنبوب (gzipped ، لا أقل).

في القوالب الخاصة بك ، تحقق مما إذا كنت في وضع التطوير ، وقمت بتضمين الملفات المنفصلة ، وإذا كان في الإنتاج ، قم بتضمين الملف النهائي (الذي يجب عليك "بناء" بنفسك).




في مشروعي الأخير - Viajeros.com - استخدمت مزيجًا من عدة تقنيات. لا أعرف كيفية تنظيم تطبيق ويب - يعد Viajeros موقعًا للتواصل الاجتماعي للمسافرين الذين لديهم أقسام محددة جيدًا ، لذلك من السهل فصل الشفرة لكل منطقة.

أستخدم محاكاة مساحة الاسم والتحميل البطيء للوحدات وفقًا لقسم الموقع. على كل حمولة صفحة ، أعلن عن كائن "vjr" ، وقم دائمًا بتحميل مجموعة من الوظائف الشائعة إليه (vjr.base.js). ثم يقرر كل صفحة HTML الوحدات التي تحتاج مع بسيطة:

vjr.Required = ["vjr.gallery", "vjr.comments", "vjr.favorites"];

يحصل Vjr.base.js على كل واحد gzipped من الخادم وينفذها.

vjr.include(vjr.Required);
vjr.include = function(moduleList) {
  if (!moduleList) return false;
  for (var i = 0; i < moduleList.length; i++) {
    if (moduleList[i]) {
      $.ajax({
        type: "GET", url: vjr.module2fileName(moduleList[i]), dataType: "script"
      });
    }
  }
};

كل "وحدة" لديها هذا الهيكل:

vjr.comments = {}

vjr.comments.submitComment = function() { // do stuff }
vjr.comments.validateComment = function() { // do stuff }

// Handlers
vjr.comments.setUpUI = function() {
    // Assign handlers to screen elements
}

vjr.comments.init = function () {
  // initialize stuff
    vjr.comments.setUpUI();
}

$(document).ready(vjr.comments.init);

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




من المؤكد أن المبدأ الأساسي لـ OO + MVC سيقطع شوطا طويلا لإدارة تطبيق javascript المعقد.

في الأساس ، أقوم بتنظيم تطبيقي وجافا سكريبت إلى التصميم المألوف التالي (الذي يوجد على طول الطريق من أيام برمجة سطح المكتب إلى الويب 2.0)

وصف للقيم الرقمية على الصورة:

  1. أدوات تمثل وجهات نظر طلبي. يجب أن يكون هذا قابلاً للتوسعة ويفصل بين الفصل الجيد الذي ينشأ بشكل دقيق والذي يحاول MVC تحقيقه بدلاً من تحويل تطبيقي إلى رمز معكرونة (مكافئ في تطبيق الويب لوضع كتلة كبيرة من جافا سكريبت مباشرة في HTML). تتواصل كل أداة عبر الآخرين عن طريق الاستماع إلى الحدث الذي تولده عناصر واجهة مستخدم أخرى وبالتالي تقليل الاقتران القوي بين الأدوات التي يمكن أن تؤدي إلى شفرة لا يمكن التحكم بها (تذكر يوم إضافة onclick في كل مكان مشيراً إلى وظائف عالمية في علامة البرنامج النصي؟ Urgh ...)
  2. نماذج الكائنات التي تمثل البيانات التي أريد نشرها في الأدوات والمرور للخلف وللأمام للخادم. عن طريق تغليف البيانات إلى نموذجها ، يصبح التطبيق لاستيعاب تنسيق البيانات. على سبيل المثال: في حين أن طرز الكائنات في جافا سكريبت هي في الغالب متسلسلة ومتسلسلة إلى JSON ، إذا كان الخادم يستخدم XML بطريقة أو بأخرى للاتصال ، كل ما أحتاج إلى تغييره هو تغيير طبقة التسلسل / إلغاء التسلسل وليس بالضرورة أن تغير جميع فئات عناصر واجهة المستخدم. .
  3. فئات التحكم التي تدير منطق الأعمال والاتصال إلى الخادم + طبقة التخزين المؤقت في بعض الأحيان. تتحكم هذه الطبقة في بروتوكول الاتصال بالخادم وتضع البيانات الضرورية في نماذج الكائنات
  4. يتم لف الطبقات بدقة في مساحات الأسماء المقابلة الخاصة بها. أنا متأكد من أننا جميعًا نعرف كيف يمكن أن تكون مساحة الاسم العالمية سيئة في Javascript.

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

jQuery هو لطيف بشكل لا يصدق وجافا سكريبت إطار وأنا أحب ذلك ، ولكن مع زيادة حجم المشروع ، أنا بحاجة إلى بنية إضافية لتطبيق الويب الخاص بي خاصة لتسهيل توحيد ممارسة OO. لنفسي ، بعد عدة تجارب ، أجد أن البنية التحتية لـ YUI3 Base و Widget ( http://yuilibrary.com/yui/docs/widget/ و http://yuilibrary.com/yui/docs/base/index.html ) توفر بالضبط ما أحتاجه. بعض الأسباب التي تجعلني أستخدمها.

  1. يوفر دعم Namespace. حاجة حقيقية لـ OO وتنظيم أنيق من التعليمات البرمجية الخاصة بك
  2. انها تدعم فكرة الطبقات والأشياء
  3. يعطي وسيلة توحيد لإضافة متغيرات الحالة إلى صفك
  4. وهو يدعم تمديد فئة بدقة
  5. يوفر منشئ و destructor
  6. ويوفر تقديم وتجميع الحدث
  7. لديها إطار القطعة الأساسية
  8. كل أداة قادرة الآن على التواصل مع بعضها البعض باستخدام النموذج المعياري القائم على الحدث
  9. الأهم من ذلك ، أنه يعطي جميع المهندسين على معيار OO لتطوير جافا سكريبت

على عكس العديد من المشاهدات ، ليس بالضرورة أن أختار بين jQuery و YUI3. هذان يمكن أن يتعايشا بسلام. في حين يوفر YUI3 قالب OO الضروري لتطبيق الويب المعقد الخاص بي ، لا يزال jQuery يزود فريقي بسهولة استخدام JS Abstraction التي نحبها ونعرفها جميعًا.

باستخدام YUI3 ، تمكنت من إنشاء نمط MVC عن طريق فصل الطبقات التي توسع القاعدة كنموذج ، والطبقات التي تمدد Widget كطريقة عرض ، وبعيدًا عن الدورة التدريبية لديك فئات أجهزة التحكم التي تقوم بإجراء المكالمات الضرورية للمنطق والخادم.

القطعة يمكن التواصل مع بعضها باستخدام نموذج يستند إلى الحدث والاستماع إلى الحدث والقيام بالمهمة اللازمة على أساس واجهة محددة مسبقا. ببساطة ، وضع هيكل OO + MVC لـ JS هو فرح بالنسبة لي.

مجرد إخلاء مسؤولية ، لا أعمل مع Yahoo! وببساطة مهندس معماري يحاول التعامل مع نفس المشكلة التي يطرحها السؤال الأصلي. أﻋﺗﻘد أﻧﮫ إذا وﺟد أي ﺷﺧص إطﺎر ﻣﮐﺎﻓ equivalent OO ، ﻓﺳوف ﯾﻌﻣل ذﻟك أﯾﺿًﺎ. في الأساس ، تنطبق هذه المسألة على التقنيات الأخرى أيضًا. الحمد لله لجميع الناس الذين جاءوا مع مبادئ OO + MVC لجعل أيام البرمجة لدينا أكثر قابلية للإدارة.




لا يزال رئيسي في العمل يتحدث عن الأوقات التي كتبوا فيها كودًا معياريًا (لغة C) ، ويشكو من مدى كرامة هذه التعليمات في الوقت الحاضر! يقال أن المبرمجين يمكنهم كتابة التجميع في أي إطار. هناك دائمًا استراتيجية للتغلب على تنظيم الكود. المشكلة الأساسية هي مع الرجال الذين يعاملون جافا سكريبت كألعاب ولا يحاولون تعلمها.

في حالتي ، أقوم بكتابة ملفات js على أساس واجهة المستخدم أو شاشة التطبيق ، مع init_screen () المناسبة. باستخدام اصطلاح تسمية معرف صحيح ، أتأكد من عدم وجود تعارض في مساحة الاسم على مستوى عنصر الجذر. في window.load () unobstrusive ، أقوم بربط الأشياء حسب معرف المستوى الأعلى.

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







إن اتباع التصميمات الجيدة لأسلوب التصميم لدى OO يقطع شوطا طويلا في جعل الشفرة سهلة الصيانة والفهم. لكن واحدة من أفضل الأشياء التي اكتشفتها في الآونة الأخيرة هي إشارات وفتحات تعرف باسم النشر / الاشتراك. ألقِ نظرة على http://markdotmeyer.blogspot.com/2008/09/jquery-publish-subscribe.html لتنفيذ jQuery بسيط.

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

أعتقد أن Dojo (و Prototype؟) يملكان نسخة مضمنة من هذه التقنية.

انظر أيضا ما هي الإشارات وفتحات؟




بالنسبة إلى مؤسسة جافا سكريبت ، استخدم ما يلي

  1. مجلد لجميع ملفات جافا سكريبت الخاصة بك
  2. يحصل javascript على مستوى الصفحة على ملفه الخاص بنفس اسم الصفحة. قد يكون ProductDetail.aspx ProductDetail.js
  3. داخل مجلد جافا سكريبت لملفات المكتبة لدي مجلد ليب
  4. ضع وظائف المكتبة ذات الصلة في مجلد lib الذي تريد استخدامه في جميع أنحاء التطبيق الخاص بك.
  5. Ajax هو javascript الوحيد الذي أقوم بنقله خارج مجلد javascript ويحصل على مجلد خاص به. ثم أقوم بإضافة اثنين من عميل المجلدات الفرعية والخادم
  6. يحصل مجلد "العميل" على كافة ملفات .js بينما يحصل مجلد الملقم على كافة ملفات جانب الخادم.



كان Dojo نظام وحدة من اليوم الأول. في الواقع ، يعتبر حجر الزاوية في Dojo ، الصمغ الذي يجمع كل ذلك معًا:

استخدام الوحدات يحقق Dojo الأهداف التالية:

  • مساحات الأسماء لرمز Dojo dojo.declare() المخصصة ( dojo.declare() ) - لا تلوث المساحة العامة ، تتعايش مع المكتبات الأخرى ، dojo.declare() غير المدركة في Dojo.
  • تحميل وحدات بشكل متزامن أو بشكل غير متزامن بالاسم ( dojo.require() ).
  • يقوم الإصدار المخصص بتحليل تبعيات الوحدة النمطية لإنشاء ملف مفرد أو مجموعة من الملفات المترابطة (تسمى طبقات) لتضمين فقط ما يحتاجه تطبيق الويب الخاص بك. يمكن أن تتضمن البنايات المخصصة وحدات Dojo ووحدات موفرة للعملاء أيضًا.
  • الوصول إلى CDN شفاف إلى Dojo ورمز المستخدم. تحمل كل من AOL و Google Dojo على هذا النحو ، ولكن بعض العملاء يفعلون ذلك لتطبيقات الويب المخصصة أيضًا.



استلهمت من وظائف سابقة أنا قدمت نسخة من أدلة Rakefile والموردين الموزعة مع WysiHat (RTE المذكورة من قبل التغيير) وقدمت بعض التعديلات لتشمل التحقق من رمز مع JSLint مع YUI Compressor .

الفكرة هي استخدام Sprockets (من WysiHat) لدمج JavaScripts متعددة في ملف واحد ، والتحقق من بنية الملف المدمج مع JSLint وتقليله باستخدام YUI Compressor قبل التوزيع.

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

  • جافا وقت التشغيل
  • روبي ورايق جوهرة
  • يجب أن تعرف كيفية وضع JAR في Classpath

القيام به الآن

  1. تحميل Rhino ووضع JAR ("js.jar") إلى classpath الخاص بك
  2. قم بتنزيل YUI Compressor ووضع JAR (بناء / yuicompressor-xyz.jar) على صفك
  3. قم بتنزيل WysiHat ونسخ دليل "المورد" إلى جذر مشروع JavaScript الخاص بك
  4. قم بتنزيل JSLint لـ Rhino ووضعه داخل دليل "المورد"

الآن أنشئ ملفًا باسم "Rakefile" في الدليل الجذر لمشروع JavaScript وأضف المحتوى التالي إليه:

require 'rake'

ROOT            = File.expand_path(File.dirname(__FILE__))
OUTPUT_MERGED   = "final.js"
OUTPUT_MINIFIED = "final.min.js"

task :default => :check

desc "Merges the JavaScript sources."
task :merge do
  require File.join(ROOT, "vendor", "sprockets")

  environment  = Sprockets::Environment.new(".")
  preprocessor = Sprockets::Preprocessor.new(environment)

  %w(main.js).each do |filename|
    pathname = environment.find(filename)
    preprocessor.require(pathname.source_file)
  end

  output = preprocessor.output_file
  File.open(File.join(ROOT, OUTPUT_MERGED), 'w') { |f| f.write(output) }
end

desc "Check the JavaScript source with JSLint."
task :check => [:merge] do
  jslint_path = File.join(ROOT, "vendor", "jslint.js")

  sh 'java', 'org.mozilla.javascript.tools.shell.Main',
    jslint_path, OUTPUT_MERGED
end

desc "Minifies the JavaScript source."
task :minify => [:merge] do
  sh 'java', 'com.yahoo.platform.yui.compressor.Bootstrap', '-v',
    OUTPUT_MERGED, '-o', OUTPUT_MINIFIED
end

إذا قمت بكل شيء بشكل صحيح ، يجب أن تتمكن من استخدام الأوامر التالية في وحدة التحكم الخاصة بك:

  • rake merge - لدمج ملفات JavaScript مختلفة في واحد
  • rake check - للتحقق من بناء الجملة من التعليمات البرمجية الخاصة بك (هذه هي المهمة الافتراضية ، بحيث يمكنك ببساطة نوع rake )
  • rake minify - لإعداد نسخة مصغرة من شفرة JS

على دمج المصدر

باستخدام Sprockets ، معالج JavaScript المسبق يمكنك تضمين (أو require ) ملفات JavaScript أخرى. استخدم بناء الجملة التالي لتضمين برامج نصية أخرى من الملف الأولي (المسمى "main.js" ، ولكن يمكنك تغيير ذلك في Rakefile):

(function() {
//= require "subdir/jsfile.js"
//= require "anotherfile.js"

    // some code that depends on included files
    // note that all included files can be in the same private scope
})();

وثم...

إلقاء نظرة على Rakefile المقدمة مع WysiHat لضبط وحدة الاختبار الآلي. أشياء لطيفة :)

والآن للحصول على الجواب

هذا لا يجيب على السؤال الأصلي بشكل جيد للغاية. أعلم وأنا آسف على ذلك ، ولكني قمت بنشره هنا لأنني آمل أن يكون من المفيد لشخص آخر تنظيم فوضى.

توجهي الخاص بالمشكلة هو القيام بأكبر قدر ممكن من النمذجة الموجّهة للكائنات وفصل التطبيقات في ملفات مختلفة. ثم يجب أن يكون معالجات قصيرة قدر الإمكان. المثال مع List مفردات هو أيضا واحد لطيف.

ومساحات الاسم ... يمكن تقليدها بشكل جيد بواسطة بنية كائن أعمق.

if (typeof org === 'undefined') {
    var org = {};
}

if (!org.hasOwnProperty('example')) {
    org.example = {};
}

org.example.AnotherObject = function () {
    // constructor body
};

أنا لست معجبًا كبيرًا بالتقليد ، ولكن قد يكون هذا مفيدًا إذا كان لديك العديد من الأشياء التي ترغب في الخروج من النطاق العالمي.




"اكتب كالمجنون وأتمنى فقط أن يعمل على أفضل وجه؟" ، لقد رأيت مشروعًا مثل هذا الذي تم تطويره وصيانته من قبل اثنين من المطورين ، تطبيق ضخم مع الكثير من كود جافا سكريبت. علاوة على ذلك ، كانت هناك اختصارات مختلفة لكل وظيفة مسجلة ممكنة يمكن التفكير فيها. اقترحت أن ينظموا الكود كمكوِّنات إضافية ، لأن هذا هو المعادل الاستفزازي للفئة ، والوحدة ، ومساحة الاسم ... والكون كله. لكن الأمور ساءت أكثر ، الآن بدأوا في كتابة الملحقات لتحل محل كل مزيج من 3 أسطر من الكود المستخدم في المشروع. Personaly أعتقد أن jQuery هو الشيطان ولا يجب استخدامه في مشاريع تحتوي على الكثير من javascript لأنه يشجعك على أن تكون كسولًا ولا تفكر في تنظيم الكود بأي طريقة. أفضّل قراءة 100 سطر من javascript من سطر واحد مع 40 وظيفة jQuery مترابطة (لست مزاح). خلافا للاعتقاد الشائع ، من السهل جدا تنظيم كود جافا سكريبت في مكافئات لمساحات وفئات الأسماء. هذا ما تفعله YUI و Dojo. يمكنك بسهولة لفة بنفسك إذا أردت. أجد نهج YUI أفضل بكثير وفعالة. ولكنك عادة ما تحتاج إلى محرر جيد مع دعم القصاصات لتعويض اصطلاحات التسمية YUI إذا كنت تريد كتابة أي شيء مفيد.




Related