Есть ли причина не предоставлять один и тот же модуль в разных исходных файлах?

Например:

// a.js
goog.provide('mypackage.a');
goog.provide('mypackage.commands');

mypackage.a.somevar = 1;

mypackage.commands.save = function(...) {...};

// b.js
goog.provide('mypackage.b');
goog.provide('mypackage.commands');

mypackage.b.somevar = 1;

mypackage.commands.read = function(...) {...};

// mypackage/commands.js
goog.provide('mypackage.commands');

mypackage.commands.runCommand = function(commandText, args) {
  return mypackage.commands[commandText](args);
}

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


person Jason Baker    schedule 25.08.2012    source источник


Ответы (2)


Нет причин, по которым вы не можете или не должны предоставлять один и тот же модуль в разных исходных файлах. Если это имеет смысл для вашей схемы организации исходного кода, то это вполне нормально. Одна из основных причин, по которой у нас есть goog.provide(), заключается в том, что один и тот же символ может использоваться в нескольких разных местах, но определен в том файле, который запускается первым.

Если я правильно понимаю goog.provide(), все, что он делает, это убеждается, что объект объявлен. Итак, goog.provide('mypackage.commands) makes sure thatmypackage.commands` объявлен в глобальной области видимости.

Итак, goog.provide('mypackage.commands'); просто выполняет что-то похожее на это:

window.mypackage = window.mypackage || {};
window.mypackage.commands = window.mypackage.commands || {};

Вам нужно сделать это только тогда, когда вы планируете добавлять что-то к этому объекту в этом исходном файле. Таким образом, если несколько исходных файлов добавляют новые элементы в mypackage.commands, то каждый исходный файл будет выполнять goog.provide('mypackage.commands)`, чтобы убедиться, что объявлена ​​правильная структура глобальной переменной.

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

Полезная справочная статья: https://developers.google.com/closure/library/docs/tutorial

person jfriend00    schedule 25.08.2012

Использование goog.provide() для определения одного и того же пространства имен в нескольких файлах не приведет к перезаписи пространства имен, поскольку каждый уровень пространства имен проверяется на существование слева направо. Однако Closure Library следует соглашению, согласно которому каждое пространство имен предоставляется только в одном файле.

Из Закрытие: полное руководство стр. 49:

Каждый файл JavaScript в библиотеке Closure начинается как минимум с одного вызова goog.provide(). Все элементы, добавленные в предоставленное пространство имен, добавляются в этот файл. Как и в Java, файлы находятся в структуре каталогов, которая параллельна пространству имен, хотя это не требуется для закрытия, как для Java. Однако это соглашение облегчает поиск файла, отвечающего за данное пространство имен. Рекомендуется следовать этому соглашению в ваших собственных проектах JavaScript, использующих Closure.

Кроме того, при использовании Closure Builder для управления зависимостями возникает следующая ошибка. когда одно и то же пространство имен предоставляется несколькими файлами.

depstree.MultipleProvideError: Пространство имен «your.namespace» указано в источниках более одного раза.

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

person Christopher Peisert    schedule 25.08.2012