JavaScript в маленьком

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

var olaBiniSeriousBanking = (function() {
  var balance = 0;

  function deposit(num) {
    balance += num;
  }

  function checkOverdraft(amount) {
    if(balance - amount < 0) {
      throw "Can't withdraw more than exists in account";
    }
  }

  function withdraw(amount) {
    checkOverdraw(amount);
    balance -= amount;
  }

  return {deposit: deposit, withdraw: withdraw};
})();

В этом случае переменная баланса полностью скрыта внутри лексического замыкания и доступна только для функций ввода и вывода. Эти функции также не находятся в глобальном пространстве имен, так что нет риска забить. Также возможно иметь много и много вспомогательных функций, которые никто не сможет увидеть. Это облегчает уменьшение ваших функций — и, кстати, самая большая проблема, с которой я сталкивался в качестве кода JavaScript, заключается в том, что функции имеют тенденцию быть очень большими. Не делай этого!

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

var olaBiniGreeterModule = (function(greeting) {
  return {greet: function(nam {
    console.log(greeting + ", " + name);
  }};
});
var olaBiniGreeterEng = olaBiniGreeterModule("Hello");
var olaBiniGreeterSwe = olaBiniGreeterModule("Hejsan");

Шаблон модуля хорош сам по себе, но есть некоторые вещи, которые может сделать загрузчик, который делает вещи еще лучше. Есть несколько вариантов этих загрузчиков модулей, но мой любимый до сих пор — RequireJS. У меня есть несколько причин для этого, но главная из них, вероятно, заключается в том, что он очень легкий и на самом деле является чистой победой даже для очень небольших веб-приложений. Позволяя RequireJS управлять вашими модулями, есть много преимуществ. Основным из них является то, что он заботится о зависимостях между модулями и загружает их автоматически. Это означает, что вы можете определить одну единственную точку входа для вашего JavaScript, а RequireJS обязательно загрузит все остальное. Еще одним хорошим аспектом RequireJS является то, что он позволяет вам вообще избегать глобальных имен. Все обрабатывается обратными вызовами внутри RequireJS. Так как это выглядит? Что ж,простой модуль с зависимостью может выглядеть так:

// in file foo.js
require(["bar", "quux"], function(bar, quux) {
  return {doSomething: function() {
    return bar.something() + quux.something();
  }};
});

<script data-main="scripts/main" src="scripts/require.js"> </script>

Это гарантирует, что foo.js и его зависимости bar.js и quux.js будут загружены до вызова функции. Однако один из аспектов JavaScript, который иногда ошибается, заключается в том, что вам нужно подождать, пока DOM не будет готов выполнить JavaScript. С RequireJS мы используем функцию ready внутри объекта require, чтобы убедиться, что мы можем что-то сделать, когда все будет готово. Ваш основной модуль всегда должен ждать, пока документ готов.

Вообще, RequireJS очень помог со структурой и зависимостями, и это позволяет очень просто разбить JavaScript на гораздо более мелкие части. Мне это очень нравится. Однако есть несколько недостатков. Главное в том, что он плохо взаимодействует с серверным JavaScript (или, по крайней мере, не взаимодействовал с ним месяц назад). Кроме того, он не обеспечивает чистый способ получить доступ к функциям модуля без их выполнения, что становится раздражающим при тестировании этих вещей. Об этом я немного подробнее расскажу в разделе о тестировании.

Нет JavaScript в HTML

Я не хочу никакого JavaScript в HTML, если я могу избежать этого. Единственный тег script должен быть тем, который запускает ваш модуль и загружает фреймворк — в моем случае RequireJS. У нас вообще нет встроенных обработчиков событий на страницах. Мы начали с того места, где на некоторых наших страницах было много обработчиков событий, и мы переориентировали его на гораздо меньшую базу кода, с которой было намного проще работать, извлекая все эти вещи в отдельные модули JavaScript. Это имеет побочный эффект: семантически идентифицировать все, с чем вы хотите работать, можно с помощью CSS-классов или атрибутов данных. Старайтесь избегать запутанных путей, чтобы найти элементы. Можно добавить некоторые дополнительные классы и атрибуты, чтобы сделать ваш JavaScript простым и понятным.

Инициатива работает на готовом

С точки зрения того, как мы структурируем модули в реальном приложении, мы фактически не делаем много работы при запуске. Вместо этого большая часть работы включает настройку обработчиков событий и так далее. Мы делаем так, чтобы модули верхнего уровня представляли метод init, который, как ожидается, будет вызываться основным модулем при запуске. Представьте себе систему, в которой у вас есть додзё в качестве основного фреймворка, и у вас есть этот код:

// foo.js
require(["bar"], function(bar) {
  function sayHello(node) {
    console.log("hello " + node);
  }

  function attachEventHandlers(dom) {
    dom.query(".fluxCapacitors").onclick(sayHello);
  }

  function init(dom) {
    bar.init(dom);
    attachEventHandlers(dom);
  }

  return {init: init};
});

// main.js
require(["foo"], function(foo) {
  require.ready(function() {
    foo.init(dojo);
  });
});

Много обратных вызовов

После того, как вы научились игнорировать многословность анонимных лямбд в JavaScript, они становятся очень удобными инструментами для создания API и вспомогательных функций. В общем, код, который мы пишем, использует много обратных вызовов и вспомогательных функций-обёрток. Я также использую функции, которые генерируют новые функции довольно свободно, делая такие вещи, как карри и подобные аспекты. Довольно типичный пример примерно такой:

function checkForChangesOn(node) {
  return function() {
    if(dojo.query(node).length() > 42) {
      console.log("Warning, flux reactor in flax");
    }
  };
}

dojo.query(".clixies").onclick(checkForChangesOn(".fluxes"));
dojo.query(".moxies").onclick(checkForChangesOn(".flexes"));