Поделиться пространством имен библиотеки JavaScript или использовать свое собственное?

Question

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

Похоже, к этому применяются два различных подхода -

1. Добавление специфических функций вашего приложения в пространство имен библиотек, например $.myCarouselfunction
2. Создание собственного пространства имен, например MyApplication.myCarouselFunction

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

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

Answer 1

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

Расширяется ли ваша функция / класс или зависит от функции, специфичной для библиотеки? Поместите это в пространство имен библиотеки.

Является ли ваша функция / библиотека классов независимой? В этом случае лучше поместить ее в пользовательское пространство имен.Это позволяет повторно использовать ваш код за пределами библиотеки, с которой он изначально использовался.

Answer 2

Лично мне нравится такой подход:

(function(namespace) {

function myPrivateFunction(){};

namespace.myPublicFunction = function(){};

})($); // passing the $ namespace, but if it clutters, 
       // we can change it to something else

Answer 3

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

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

MyApplication.exportName = function(objToExportTo, name, obj) {
  if (objToExportTo[name] === undefined) {
    objToExportTo[name] = obj;
  } else {
    // Possibly assert!
  }
};

MyApplication.myCarouselFunction = function() { ... };
MyApplication.exportName($, 'myCarouselFunction', MyApplication.myCarouselFunction);

Answer 4

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

В любом случае вам обычно следует создать только одно «глобальное» имя. Другими словами, если вы собираетесь поместить свою функцию в пространство имен библиотеки, лучше не называть ее $ .myFn. Назовите его $ .yaya3.myFn, а затем кэшируйте локальную ссылку на него в любом контексте, где вы вызываете myFn несколько раз.

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

(function (yaya3) {   
var myFn = yaya3.myFn;
myFn("frobnard!");
}(window.yaya3)); // you could instead pass $.yaya3 or YUI.namespace("yaya3") here

Это значительно облегчает задачу, если вы обнаружите, что вам нужно перейти в другое пространство имен.

Answer 5

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