Пространство имен Javascript с помощью RequireJS, почему?

Question

Пространство имен Javascript с помощью RequireJS, почему?

В настоящее время я сталкиваюсь с этим аргументом о пространствах имен в javascript, и мне нужно мнение сообщества.

Сценарий: архитектор, отвечающий за этот проект, каким-то образом посвящен RequireJS и действительно хочет его использовать.

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

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

Главный вопрос: Зная, о каком приложении мы говорим, почему именно RequireJS?

Второй вопрос: зачем пытаться убедить, что лучший подход к пространству имен в javacript - это использование RequireJS? Я что-то пропустил?

Мое мнение: для меня это не имеет никакого смысла вообще. Использовать RequireJS здесь неудобно, потому что по требованию не загружается ни один ресурс, все они загружаются при загрузке страницы (только потому, что они нужны нам при загрузке страницы). Нам нужно поддерживать как минимум IE8, Chrome, Firefox и Opera, и у нас уже было много проблем с загрузкой ресурсов во всех этих браузерах. Уже есть много хитростей, чтобы убедиться, что все загружается, как и ожидалось, через Require.

Для пространства имен это еще хуже. Конечно, это работает, но опять же, мне кажется обременительным и в этом вопросе на самом деле очень ограничен.

Так я что-то упустил? Мне нужно третье (или сотое) мнение здесь.

Что ты думаешь об этом?
Что ты используешь?
Зачем?

заранее спасибо

6

javascript jquery requirejs javascript-namespaces

Источник

user140472 17 дек '12 в 20:22

4 ответа

Другие вопросы по тегам javascript jquery requirejs javascript-namespaces

user88558 17 дек '12 в 20:42 2012-12-17 20:42 · Answer 1 · 2012-12-17 20:42

Загрузчики AMD (RequireJS - один) решают различные проблемы:

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

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

user120513 17 дек '12 в 20:44 2012-12-17 20:44 · Answer 2 · 2012-12-17 20:44

Независимо от того, является ли это "одностраничным приложением" или нет, RequireJS помогает с двумя вещами, которые непросты без большой дисциплины разработчика при разработке клиентского JavaScript:

Среда производства и разработки

Теперь здравый смысл разбивать ваши приложения JavaScript на файлы, которые логически похожи на разные части вашего приложения. Это легче отлаживать и поддерживать. Однако в производстве доставка многих несжатых файлов плохо сказывается на производительности. Таким образом, вы объединяете все свои файлы в один файл, минимизируете его (например, с помощью компилятора Google Closure), а затем отправляете его как один сжатый файл. Есть много разных способов сделать это с помощью инструментов командной строки (например, с помощью GruntJS), но без загрузчика скриптов, такого как RequireJS, вам каким-то образом придется настраивать страницу для двух разных вариантов использования (ссылаться на все ваши файлы dev как теги скрипта или единый продукт)..js) себя. RequireJS имеет инструмент сборки NodeJS, который делает все это за вас.

Модульность

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

Читайте также в разделе " Почему веб-модули " в документации RequireJS.

user1115554 17 дек '12 в 20:44 2012-12-17 20:44 · Answer 3 · 2012-12-17 20:44

По моему личному мнению, использование системы модулей javascript почти никогда не является плохой идеей. Requirejs также не единственный возможный загрузчик для модулей JavaScript (но, возможно, самый популярный). Некоторые альтернативы - LABjs или HeadJS.

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

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

user140472 18 дек '12 в 09:07 2012-12-18 09:07 · Answer 4 · 2012-12-18 09:07

Мое текущее решение по предотвращению загрязнения глобальной среды и столкновений имен заключается в использовании $.extend,

Дерево файловой системы выглядит примерно так:

RootFolder
  +-> js
  global.js
  ...
   +-> views
       index.js
       page1.js
       page2.js
       ...
index.html
page1.html
page2.html

Так что обычно это один файл global.js со всем общим кодом приложения и другой файл для каждой страницы.

Для пространства имен мне нравится $.extend, поэтому в каждом файле js у меня есть что-то вроде:

var app = app || {};  

/* only one document ready block per view if needed */
$(document).ready(function(){
    /* initialization code */
});

/* extend the app namespace with the Page1 code */
$.extend(app, {
    page1: {
        SayHi: function SayHi(name){
            alert('Hi ' + name);
        }
    }
});

Таким образом, вы можете получить доступ к своему коду по телефону:

app.page1.SayHi("Alex");

С помощью этой техники вы:

Иметь полный контроль над вашим кодом. Никакой загрузки магических ресурсов и необычных вещей, над которыми у вас нет полного контроля.
Нет глобального загрязнения окружающей среды
Нет конфликтов имен
Дерево пространства имен может быть настолько глубоким, насколько вы пожелаете, вы являетесь владельцем собственной сложности.
У вас может быть несколько js-файлов, которые фактически соответствуют одному и тому же уровню пространства имен. Это особенно полезно для вспомогательных инструментов.
В зависимости от javascript-файлов, которые вы включаете в страницу, вы можете использовать пространство имен приложения большего или меньшего размера.

Заключение:

Веб-среда действительно проста, мы не должны усложнять это.

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

Поэтому, если мне не нужна основная функция, нет смысла ее использовать.

Ура!