При использовании символов (функций, констант, глобальных переменных), определенных в других файлах JavaScript, я передаю их «функции определения объема» текущего файла (функции верхнего уровня, обычно анонимной, предотвращающей загрязнение глобального пространства имен) в качестве параметров:
![multiple containers](https://i.stack.imgur.com/Dmo57.png)
Как видно из скриншота, ReSharper (6.0.2202.688) доволен jQuery
, ContainerA
и ContainerB
, даже если они не определены нигде в текущем файле. Комментарий в строке 1 предназначен только для JSLint (без ошибок).
Этот метод предполагает, что все другие файлы JavaScript следуют наилучшей практике JavaScript по минимальному загрязнению глобального пространства имен путем определения одного объекта верхнего уровня, который содержит все экспортируемые ( публичные ) символы (т.е. * 1013). * является единственным глобальным объектом для библиотеки jQuery и ее плагинов, ContainerA
является единственным глобальным объектом для LibraryA, ContainerB
является единственным глобальным объектом для LibraryB и т. д.).
Поскольку вы явно не можете контролировать веб-методы ASP.NET, генерирующие функции конструктора в глобальном пространстве имен, в вашем случае вам придется прибегнуть к конечному контейнеру, window
:
![window as a container](https://i.stack.imgur.com/pMECM.png)
Это небольшое изменение в методике, предложенной @sethobrien в его комментарии. Важным (ИМХО) преимуществом является то, что вы не жестко кодируете window.X
в своем коде. Вместо этого ваш код создает экземпляры классов из контейнера aspNet
(который на данный момент является синонимом для window
, но может измениться в будущем). Кроме того, наличие aspNet.X
в коде более четко декларирует ваше намерение для людей, которые будут читать ваш код в будущем. Наконец, локальные переменные могут быть сокращены с помощью минимизаторов JavaScript, что приводит к получению файла небольшого размера, передаваемого в клиентские браузеры.