Управление Javascript

Question

Как вы управляете содержимым Javascript на более крупном веб-сайте? Я особенно борется с различными $ (document) .ready() и тем фактом, что мне нужно жонглировать всеми этими строками id ($ ('# id')). Я думал о объединении необходимого $ (document) .ready() с каждым «модулем», который их использует, но это приводит к ухудшению видимой скорости, поскольку у меня больше нет javascript внизу каждой страницы.

Что такое хороший способ эффективного управления Javascript довольно большого сайта и его легко поддерживать?

Answer 1

Я не знаю, как выглядит ваша среда. Но я думаю, что списание сценария на разные сегменты. Весь код, специфичный для конкретной страницы или функции, должен находиться в файле javascript.

Далее приведены условные обозначения и стандарты.

Последнее, но самое главное, документировать все. Когда страница меняется, вы должны посмотреть в своей документации, какие сценарии она может повлиять. Точно так же документация должна быть в состоянии рассказать вам, что сценарий делает, что на каких страницах.

Я знаю, что это не прямой ответ на ваш вопрос, но это облегчит обслуживание в долгосрочной перспективе. Особенно, если много людей работают над одним и тем же проектом.

Когда речь идет о поддерживаемом коде, соглашения об именах снова очень важны. И в части html и javascript. Также переменные javascript и функции должны как можно больше отражать HTML-код. Например, если у вас есть форма id = "banana", не называйте переменную, удерживающую ее "apple".

Answer 2

Это то, что пришло мне в голову в это время, надеюсь, вы сможете помочь. нести ответственность за упорядоченные методы вызова каждого модуля, и все они вызываются в одном событии. какого уровня в случае, если необходимо вызвать какой-либо модуль перед другим

// Call the initial organizer of each modules 
var modules = (function(){ 

    var level_0 = new Array(); 
    var level_1 = new Array(); 
    var level_2 = new Array(); 

    return { 
     add: function(method, level){ 
      var returned = true; 
      try{ 
       switch(level){ 
        case 0: 
         level_0.push(method); 
         break; 
        case 1: 
         level_1.push(method); 
         break; 
        case 2: 
         level_2.push(method); 
         break; 
       }; 
      }catch(ex){returned=false;} 
      return returned; 
     }, 
     callAll: function(){ 
      var returned = true; 
      var returned_0 = true; 
      var returned_1 = true; 
      var returned_2 = true; 
      try{ 
       returned_0 = this.call(0); 
       returned_1 = this.call(1); 
       returned_2 = this.call(2); 
      }catch(ex){returned=false;} 
      return ((returned && returned_0 && returned_1 && returned_2) || false); 
     }, 
     call: function(level){ 
      var returned = true; 
      var level_call = null; 
      try{ 
       switch(level){ 
        case 0: 
         level_call = level_0; 
         break; 
        case 1: 
         level_call = level_1; 
         break; 
        case 2: 
         level_call = level_2; 
         break; 
       }; 

       if (level_call!=null) 
        for(xcall in level_call) 
         level_call[xcall].call(); 

      }catch(ex){returned=false;} 
      return returned; 
     } 
    }; 
})(); 

//in each file JS with ini method in module 
modules.add(function(){alert("method file/module A in level 1 a");}, 1); 
modules.add(function(){alert("method file/module B in level 1 b");}, 1); 
modules.add(function(){alert("method file/module C in level 0 a");}, 0); 
modules.add(function(){alert("method file/module D in level 0 b");}, 0); 
modules.add(function(){alert("method file/module E in level 2 a");}, 2); 
modules.add(function(){alert("method file/module F in level 2 b");}, 2); 
modules.add(function(){alert("method file/module G in level 2 c");}, 2); 
modules.add(function(){alert("method file/module H in level 0 c");}, 0); 


// single call to the event ready 
$(function(){ 
    //call all 
    modules.callAll(); 

    // OR 

    //call in other order 
    modules.call(0); 
    modules.call(2); 
    modules.call(1); 
}); 

Answer 3

Посмотрите, как библиотеки, как Dojo и ExtJS управлять этим для идей. Они используют такие функции, как require(), чтобы извлекать динамически зависящие от них сценарии и обеспечивать, чтобы эти обычные библиотеки не загружались дважды. Они определяют события для обработки зависимостей нагрузки, так что, например, ваш большой список операторов .ready() может быть реорганизован в некоторых местах, чтобы вместо этого быть одной важной инициализацией библиотеки, а затем отключить одно или несколько событий, чтобы указать, что некоторые вещи готовы, что другие библиотеки используют их для инициализации.

Одна вещь, которую мне нравится делать, когда несколько кодеров кодируются с одной и той же кодовой базой, заключается в использовании HTML/DOM в качестве взаимного договора и привязки кода к ней с помощью селекторов, а не разрешению встроенных событий.

Например, если вы пишете элемент управления календарем, который имеет onclick на теге img, который должен показывать календарь, вы затрудняетесь с тем, чтобы еще две библиотеки вошли и отключали «календарь» контроль собирается всплывающее событие. С другой стороны, если библиотека ищет элементы с именем класса CSSName «calendarPick» и прикрепляет к ним событие, то вы оставляете открытые другие библиотеки, чтобы делать то, что они будут, с тем же DOM, с которым вы делитесь, с небольшой или никакой координацией между кодеры (код записи, требующий координации кодера, как правило, замедляет кодирование и увеличивает вероятность того, что что-то сломается).

Если эта библиотека календарей предлагает некоторые события, чтобы от нее от нее отказаться, другие кодеры выполняют свою работу, поскольку, если событие уже существует, они, скорее всего, напишут это чисто; если это не так, они могут взломать его и сделать базу кода менее гибкой в ​​этом процессе.

Если вы предлагаете методы singleton, например Calendar.getCalendars(), вы также облегчите совместную работу, потому что это мешает людям писать собственную версию этих методов, блокируя реализацию до определенного набора имена классов, порядок DOM или даже более хрупкие обстоятельства, чтобы все версии этого продолжали работать.

Answer 4

Если вы ищете хороший ресурс для написания хорошего и чистого JS, вам может потребоваться книга Дугласа Крокфорда JavaScript: The Good Parts, так как она содержит много полезных ресурсов, включая советы о том, как хорошо структурировать код.

Когда я пишу приложения, у которых много JS, я обычно создаю один объект (чтобы не загромождать глобальное пространство имен), а затем делить его на под-объекты, которые содержат различные биты данных и поведения приложения. Небольшой пример:

var PandaApp = {}; 
PandaApp.setup = {}; 
PandaApp.setup.init = function init() { 
    // do something neat 
}; 
PandaApp.utils = {}; 
PandaApp.utils.showMessage = function showMessage(msg) { 
    // do some jQuery goodness or something 
}; 

Таким образом, у меня есть ровно один глобальный объект со всеми моими данными в нем и все это аккуратно пространство имен в манере моего выбора.