Общепринятые лучшие практики организации кода в JavaScript

Было бы намного приятнее, если бы в javascript были встроены пространства имен, но я обнаружил, что организация таких вещей, как Дастин Диаз, описывает здесь, помогает мне много,

var DED = (function() {

    var private_var;

    function private_method()
    {
        // do stuff here
    }

    return {
        method_1 : function()
            {
                // do stuff here
            },
        method_2 : function()
            {
                // do stuff here
            }
    };
})();

Я помещаю разные "пространства имен", а иногда и отдельные классы в отдельные файлы. Обычно я начинаю с одного файла и как класс или пространство имен становится достаточно большим, чтобы гарантировать это, я разделяю его на свой собственный файл. Использование инструмента для объединения всех ваших файлов для производства - отличная идея.

Я стараюсь избегать включения javascript в HTML. Весь код инкапсулируется в классы, и каждый класс находится в собственном файле. Для разработки у меня есть отдельный <script> теги для включения каждого js файла, но они объединяются в один более крупный пакет для производства, чтобы уменьшить накладные расходы HTTP-запросов.

Как правило, у меня будет один "главный" js файл для каждого приложения. Итак, если бы я писал приложение "опрос", у меня был бы файл js под названием "survey.js". Это будет содержать точку входа в код jQuery. Я создаю ссылки jQuery во время создания экземпляра, а затем передаю их в свои объекты в качестве параметров. Это означает, что классы javascript являются "чистыми" и не содержат ссылок на идентификаторы 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 будет стандартным классом javascript, который просто использует 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>');
  //...
};

Я использовал несколько сложных приложений, используя этот подход.

Вы можете разбить свои сценарии на отдельные файлы для разработки, а затем создать версию "выпуска", где вы соедините все вместе и запустите YUI Compressor или что-то подобное на нем.

Вдохновленный более ранними сообщениями я сделал копию каталогов Rakefile и поставщиков, распространяемых с помощью WysiHat (RTE, упомянутый в журнале изменений) и внес несколько изменений, включая проверку кода с помощью JSLint и minification с Компрессор YUI.

Идея состоит в том, чтобы использовать Sprockets (из WysiHat), чтобы объединить несколько JavaScripts в один файл, проверить синтаксис объединенного файла с JSLint и минимизировать его с помощью компрессора YUI перед распространением.

Предпосылки

• Java Runtime
• рубиновый и граблиный камень
• Вы должны знать, как поставить JAR в Classpath

Теперь сделайте

• Загрузите Rhino и поместите JAR ( "js.jar" ) в свой путь к классам
• Загрузите YUI Compressor и поместите JAR (build/yuicompressor-xyz.jar) в свой путь к классам
• Загрузите WysiHat и скопируйте каталог "vendor" в корень вашего проекта JavaScript
• Загрузите JSLint для Rhino и поместите его в каталог "vendor"

Теперь создайте файл с именем "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 singleton также хорош.

И пространства имен... ну, они могут быть имитированы более глубокой структурой объекта.

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

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

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

Я не большой поклонник имитаций, но это может быть полезно, если у вас есть много объектов, которые вы хотели бы вывести из глобальной области.

Организация кода требует принятия стандартов и стандартов документации:
1. Код пространства имен для физического файла;

Exc = {};

2. Групповые классы в этих пространствах имен javascript;
3. Установите прототипы или связанные функции или классы для представления объектов реального мира;

Exc = {};
Exc.ui = {};
Exc.ui.maskedInput = function (mask) {
    this.mask = mask;
    ...
};
Exc.ui.domTips = function (dom, tips) {
    this.dom = gift;
    this.tips = tips;
    ...
};

4. Установите соглашения, чтобы улучшить код. Например, группируйте все свои внутренние функции или методы в свой атрибут класса объекта.

Exc.ui.domTips = function (dom, tips) {
    this.dom = gift;
    this.tips = tips;
    this.internal = {
        widthEstimates: function (tips) {
            ...
        }
        formatTips: function () {
            ...
        }
    };
    ...
};

5. Сделайте документацию пространств имен, классов, методов и переменных. При необходимости также обсуждать некоторые из кода (некоторые FI и Fors, они обычно реализуют важную логику кода).

/**
  * Namespace <i> Example </i> created to group other namespaces of the "Example".  
  */
Exc = {};
/**
  * Namespace <i> ui </i> created with the aim of grouping namespaces user interface.
  */
Exc.ui = {};

/**
  * Class <i> maskdInput </i> used to add an input HTML formatting capabilities and validation of data and information.
  * @ Param {String} mask - mask validation of input data.
  */
Exc.ui.maskedInput = function (mask) {
    this.mask = mask;
    ...
};

/**
  * Class <i> domTips </i> used to add an HTML element the ability to present tips and information about its function or rule input etc..
  * @ Param {String} id - id of the HTML element.
  * @ Param {String} tips - tips on the element that will appear when the mouse is over the element whose identifier is id <i> </i>.
  */
  Exc.ui.domTips = function (id, tips) {
    this.domID = id;
    this.tips = tips;
    ...
};

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

Следуя хорошим принципам дизайна OO и шаблонам проектирования, вы проделаете долгий путь, чтобы сделать ваш код удобным для понимания и понимания. Но одна из лучших вещей, которые я обнаружил недавно, это сигналы и слоты, которые вы можете опубликовать/подписаться. Посмотрите http://markdotmeyer.blogspot.com/2008/09/jquery-publish-subscribe.html для простой реализации jQuery.

Идея хорошо используется на других языках для разработки графического интерфейса. Когда что-то существенное происходит где-то в вашем коде, вы публикуете глобальное синтетическое событие, к которому могут подписаться другие методы в других объектах. Это дает отличное разделение объектов.

Я думаю, что Dojo (и Prototype?) имеют встроенную версию этой техники.

см. также Что такое сигналы и слоты?

Мне удалось успешно применить шаблон

Dojo имела модульную систему с первого дня. На самом деле он считается краеугольным камнем Dojo, клей, который держит его все вместе:

• dojo.require — официальный документ.
• Понимание dojo.declare, dojo.require и dojo.provide.
• Представляем Dojo.

Использование модулей Dojo достигает следующих целей:

• Пространства имен для Dojo кода и пользовательского кода (dojo.declare()) — не загрязнять глобальное пространство, сосуществовать с другими библиотеками и пользовательским кодом Dojo -aware.
• Загрузка модулей синхронно или асинхронно по имени (dojo.require()).
• Пользовательские сборки, анализируя зависимости модулей для создания одного файла или группы взаимозависимых файлов (так называемые слои), включают только то, что нужно вашему веб-приложению. Пользовательские сборки могут включать модули Dojo и модули, поставляемые заказчиком.
• Прозрачный доступ на основе CDN к Dojo и коду пользователя. И AOL, и Google несут Dojo таким образом, но некоторые клиенты делают это также для своих пользовательских веб-приложений.

Я удивлен, что никто не упоминает рамки MVC. Я использовал Backbone.js для модуляции и развязки кода, и это было бесценно.

Существует немало таких структур, и большинство из них тоже очень маленькие. Мое личное мнение заключается в том, что если вы собираетесь писать больше, чем просто пару строк jQuery для flashy UI, или хотите использовать богатое приложение Ajax, структура MVC значительно упростит вашу жизнь.

Отъезд JavasciptMVC.

Вы можете:

• Разделите свой код на модели, представления и уровни контроллера.

• сжать весь код в один производственный файл

• автоматически сгенерированный код

• создать и запустить модульные тесты

• и многое другое...

Лучше всего, он использует jQuery, поэтому вы можете использовать и другие плагины jQuery.

Мой босс все еще говорит о временах написания модульного кода (язык C) и жалуется на то, как дерьмовый код в наши дни! Говорят, что программисты могут писать сборку в любых рамках. Всегда существует стратегия преодоления организации кода. Основная проблема связана с парнями, которые рассматривают java script как игрушку и никогда не пытаются ее изучить.

В моем случае я пишу js файлы в теме пользовательского интерфейса или на экране приложения, с соответствующим init_screen(). Используя правильное соглашение об именах имен, я уверен, что на уровне корневого элемента конфликтов имен нет. В unobstrusive window.load() я привязываю вещи вверх на основе идентификатора верхнего уровня.

Я строго использую java script закрытия и шаблоны, чтобы скрыть все частные методы. После этого никогда не сталкивались с проблемой противоречивых определений свойств/функций/переменных. Однако при работе с командой часто бывает сложно обеспечить такую ​​же строгость.

"Напиши, как сумасшедший, и просто надеемся, что это сработает для лучшего?", я видел такой проект, который был разработан и поддерживается только двумя разработчиками - огромным приложением с большим количеством кода javascript. Кроме того, были разные ярлыки для каждой возможной функции jquery, о которой вы можете думать. Я предложил организовать код как плагины, так как это эквивалент jquery класса, модуля, пространства имен... и всего юниверса. Но все стало намного хуже, теперь они начали писать плагины, заменяя каждую комбинацию из трех строк кода, используемых в проекте. Personaly Я думаю, что jQuery - это дьявол, и он не должен использоваться в проектах с большим количеством javascript, потому что он поощряет вас быть ленивым и не думать об организации кода в любом случае. Я бы предпочел читать 100 строк javascript, чем одну строку с 40 связанными функциями jQuery (я не шучу). Вопреки распространенному мнению, очень легко организовать javascript-код в эквивалентах пространств имен и классов. То, что делают YUI и Dojo. Вы можете легко перевернуть свои собственные, если хотите. Я нахожу подход YUI намного лучше и эффективнее. Но вам обычно нужен хороший редактор с поддержкой фрагментов, чтобы компенсировать соглашения об именах YUI, если вы хотите написать что-нибудь полезное.

Я создаю синглеты для каждой вещи, которую мне действительно не нужно создавать несколько раз на экране, классы для всего остального. И все они помещаются в одно и то же пространство имен в том же файле. Все прокомментировано и составлено с использованием диаграмм состояний UML. Код javascript очищен от html, поэтому нет встроенного javascript, и я склонен использовать jquery для минимизации проблем с перекрестным браузером.

Хороший руководитель OO + MVC определенно проделает долгий путь для управления сложным javascript-приложением.

В основном я организую свое приложение и javascript для следующего знакомого дизайна (который существует на всем пути от моего рабочего дня программирования до Web 2.0)

Описание для числовых значений изображения:

• Виджеты, представляющие представления моего приложения. Это должно быть расширяемо и четко разделено на то, что MVC пытается добиться, а не превращать мой виджет в код спагетти (эквивалент в веб-приложении для размещения большого блока Javascript непосредственно в HTML). Каждый виджет общается через других, слушая событие, созданное другими виджетами, тем самым уменьшая сильную связь между виджетами, которые могут привести к неуправляемому коду (помните день добавления onclick всюду, указывая на глобальные функции в теге script?.)
• Объектные модели, представляющие данные, которые я хочу заполнить в виджетах и ​​передавая их обратно на сервер. Инкапсулируя данные в свою модель, приложение становится агностиком формата данных. Например: хотя, естественно, в Javascript эти объектные модели в основном сериализуются и десериализуются в JSON, если каким-то образом сервер использует XML для связи, все, что мне нужно изменить, это изменение уровня сериализации/десериализации, и необязательно необходимо изменить все классы виджетов.
• Классы контроллеров, которые управляют бизнес-логикой и связи с сервером + иногда кэшируют уровень. Этот уровень управляет протоколом связи с сервером и помещает необходимые данные в модели объектов.
• Классы аккуратно завернуты в соответствующие им пространства имен. Я уверен, что все мы знаем, как неприятное глобальное пространство имен может быть в Javascript.

В прошлом я отделял файлы от своих js и использовал обычную практику для создания принципов OO в Javascript. Проблема, которую я вскоре обнаружил, что существует несколько способов написания JS OO, и это не обязательно, что все члены команды имеют одинаковый подход. По мере увеличения команды (в моем случае более 15 человек) это становится сложным, поскольку нет стандартного подхода для объектно-ориентированного Javascript. В то же время я не хочу писать свои собственные рамки и повторять часть работы, в которой я уверен, умнее людей, чем я решил.

jQuery невероятно хорош, как Javascript Framework, и мне это нравится, однако по мере того, как проект становится больше, мне явно нужна дополнительная структура для моего веб-приложения, особенно для упрощения стандартизации практики OO. Для меня после нескольких экспериментов я обнаружил, что база и виджет YUI3 (http://yuilibrary.com/yui/docs/widget/ и http://yuilibrary.com/yui/docs/base/index.html) инфраструктура обеспечивает именно то, что мне нужно. Несколько причин, по которым я их использую.

• Он обеспечивает поддержку пространства имен. Настоящая потребность в OO и аккуратная организация вашего кода.
• Поддерживает понятие классов и объектов
• Он дает стандартное средство для добавления переменных экземпляра в ваш класс
• Он поддерживает расширение класса аккуратно
• Он предоставляет конструктор и деструктор
• Он обеспечивает привязку реквизита и события
• Он имеет базовую структуру виджета
• Каждый виджет теперь может общаться друг с другом с использованием стандартной модели на основе событий
• Самое главное, это дает всем инженерам стандарт OO для разработки Javascript.

Вопреки многим представлениям, мне не обязательно выбирать между jQuery и YUI3. Эти двое могут мирно сосуществовать. Хотя YUI3 предоставляет необходимый шаблон OO для моего сложного веб-приложения, jQuery по-прежнему предоставляет моей команде простую в использовании абстракцию JS, которую мы все любим и знакомы.

Используя YUI3, мне удалось создать шаблон MVC, разделив классы, расширяющие базу как модель, классы, расширяющие виджет как вид и вне курса, у вас есть классы контроллера, которые делают необходимую логику и вызовы на стороне сервера.

Виджет может взаимодействовать друг с другом с использованием модели на основе событий и прослушивания события и выполнения необходимой задачи на основе предопределенного интерфейса. Проще говоря, размещение структуры OO + MVC для JS - это радость для меня.

Просто отказ от ответственности, я не работаю для Yahoo! и просто архитектор, который пытается справиться с той же проблемой, что и исходный вопрос. Я думаю, что если кто-то найдет эквивалентную структуру OO, это тоже сработает. В основном этот вопрос относится и к другим технологиям. Слава Богу всем людям, которые придумали Принципы OO + MVC, чтобы сделать наши дни программирования более управляемыми.

Организация кода в JQuery Centric NameSpace может выглядеть следующим образом... и не будет конфликтовать с другим Javascript API, таким как Prototype, Ext либо.

<script src="jquery/1.3.2/jquery.js" type="text/javascript"></script>
<script type="text/javascript">

var AcmeJQ = jQuery.noConflict(true);
var Acme = {fn: function(){}};

(function($){

    Acme.sayHi = function()
    {
        console.log('Hello');
    };

    Acme.sayBye = function()
    {
        console.log('Good Bye');
    };
})(AcmeJQ);

// Usage
//          Acme.sayHi();
// or
// <a href="#" onclick="Acme.sayHi();">Say Hello</a>


</script>

Надеюсь, что это поможет.

Я использую Dojo управление пакетами (dojo.require и dojo.provide) и систему классов (dojo.declare, которая также допускает простое множественное наследование) для модуляции всех моих классов/виджетов в отдельные файлы. Не только доза, это упорядочивает ваш код, но также позволяет делать ленивые/просто во времени загрузку классов/виджетов.

В моем последнем проекте -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);

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

Использовать шаблоны наследования для организации больших приложений jQuery.

Создайте поддельные классы и убедитесь, что все, что может быть выбрано в отдельную функцию, имеет смысл. Также не забудьте много комментировать, а не писать код спагетти, а не хранить все в разделах. Например, какой-то бессмысленный код, изображающий мои идеалы. Очевидно, что в реальной жизни я также пишу много библиотек, которые в основном охватывают их функциональность.

$(function(){
    //Preload header images
    $('a.rollover').preload();

    //Create new datagrid
    var dGrid = datagrid.init({width: 5, url: 'datalist.txt', style: 'aero'});
});

var datagrid = {
    init: function(w, url, style){
        //Rendering code goes here for style / width
        //code etc

        //Fetch data in
        $.get(url, {}, function(data){
            data = data.split('\n');
            for(var i=0; i < data.length; i++){
                //fetching data
            }
        })
    },
    refresh: function(deep){
        //more functions etc.
    }
};

Несколько дней назад ребята из 37Signals выпустили элемент управления RTE с завихрением. Они создали библиотеку, которая связывает файлы javascript с использованием команд предварительного процессора.

Я использую его с тех пор, чтобы отделить мои JS файлы, а затем объединить их как один. Таким образом, я могу разделить проблемы и, в конце концов, иметь только один файл, который проходит через трубу (gzipped, не менее).

В ваших шаблонах проверьте, находитесь ли вы в режиме разработки и включаете отдельные файлы, а если в процессе производства, включите последний (который вам придется "строить" самостоятельно).

Вы можете использовать jquery mx (используемый в javascriptMVC), который представляет собой набор скриптов, который позволяет использовать модели, представления и контроллеры. Я использовал его в проекте и помог мне создать структурированный javascript с минимальными размерами script из-за сжатия. Это пример контроллера:

$.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'));

Вы также можете использовать только сторону контроллера jquerymx, если вас не интересуют детали представления и модели.

Я использую эту маленькую вещь. Он дает вам директиву include для шаблонов JS и HTML. Он полностью уничтожает беспорядок.

https://github.com/gaperton/include.js/

$.include({
    html: "my_template.html" // include template from file...
})
.define( function( _ ){ // define module...
    _.exports = function widget( $this, a_data, a_events ){ // exporting function...
        _.html.renderTo( $this, a_data ); // which expands template inside of $this.

        $this.find( "#ok").click( a_events.on_click ); // throw event up to the caller...
        $this.find( "#refresh").click( function(){
            widget( $this, a_data, a_events ); // ...and update ourself. Yep, in that easy way.
        });
    }
});

Для организации JavaScript использовались следующие

• Папка для всех ваших javascript
• Уровень страницы javascript получает свой собственный файл с тем же именем страницы. ProductDetail.aspx будет ProductDetail.js
• В папке javascript для файлов библиотеки у меня есть папка lib
• Поместите связанные библиотечные функции в папку lib, которую вы хотите использовать во всем приложении.
• Ajax - единственный javascript, который я перемещаю вне папки javascript и получает его собственную папку. Затем я добавляю два подпапки клиента и сервера
• Клиентская папка получает все .js файлы, в то время как папка сервера получает все файлы на стороне сервера.

Я думаю, что это связано, возможно, с DDD (Domain-Driven Design). Приложение, над которым я работаю, хотя и не имеет формального API, действительно дает намеки на это с помощью кода на стороне сервера (имена классов/файлов и т.д.). Вооружившись этим, я создал объект верхнего уровня в качестве контейнера для всей проблемной области; затем я добавил пространства имен в случае необходимости:

var App;
(function()
{
    App = new Domain( 'test' );

    function Domain( id )
    {
        this.id = id;
        this.echo = function echo( s )
        {
            alert( s );
        }
        return this;
    }
})();

// separate file
(function(Domain)
{
    Domain.Console = new Console();

    function Console()
    {
        this.Log = function Log( s )
        {
            console.log( s );
        }
        return this;
    }
})(App);

// implementation
App.Console.Log('foo');

Ваш вопрос - тот, который мучил меня в конце прошлого года. Разница - передача кода новым разработчикам, которые никогда не слышали о частных и общедоступных методах. Мне нужно было создать что-то простое.

Конечным результатом был небольшой (около 1 КБ) фреймворк, который переводит объектные литералы в jQuery. Синтаксис визуально легче сканировать, и если ваш js становится очень большим, вы можете писать повторно используемые запросы, чтобы найти такие вещи, как используемые селектора, загруженные файлы, зависимые функции и т.д.

Опубликовать небольшую структуру здесь нецелесообразно, поэтому я написал сообщение с примерами (Мой первый. Это было приключение!). Вы можете взглянуть.

Для любых других здесь, с несколькими минутами, чтобы проверить это, я очень благодарен за обратную связь!

FireFox рекомендуется, так как он поддерживает toSource() для примера запроса объекта.

Ура!

Адам

Lazy Загрузите код, который вам нужен по запросу. Google делает что-то подобное с помощью google.loader

Вы не упомянули, что такое серверный язык. Или, что более уместно, какие рамки вы используете - если есть - на стороне сервера.

IME, я организовываю вещи на серверной стороне и позволяю всему этому встряхнуться на веб-странице. Рамке задана задача организовать не только JS, загружаемую каждой страницей, но и фрагменты JS, которые работают с созданной разметкой. Такие фрагменты, которые вы обычно не хотите излучать больше, чем один раз - вот почему они абстрагируются в рамках этого кода, чтобы заботиться об этой проблеме.: -)

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

Обратите внимание, что ничто из этого не освобождает вас от написания эффективного JavaScript!: -)

Я использую пользовательский script, вдохновленный поведением Бена Нолана (я не могу найти текущую ссылку на это больше, к сожалению), чтобы хранить большинство моих обработчиков событий. Например, эти обработчики событий запускаются элементами className или Id. Пример:

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

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

});

Мне нравится включать большинство моих Javascript-библиотек "на лету", кроме тех, которые содержат глобальное поведение. Я использую Zend Framework headScript() помощник заполнителя для этого, но вы также можете используйте javascript для загрузки других скриптов на лету, например Ajile.