Именно поэтому переменные объявленные через var видно только внутри модуля.
Так же следует помнить о том, что require возвращает поле exports объекта module, поэтому если мы хотим вернуть свой объект мы должны переопределять это поле.
Полностью согласен. Бесплатный продукт во имя добра, распростроняемый через халявный хостинг гитхаба, но при этом с закрытыми исходниками, даже у не параноиков вроде меня, вызывает недоверие.
сторонние библиотеки устанавливаются через bower и указываются в c.json. Например для указания зависимости от angulara в c.json добавляем «bower»: ['@ angular'] (пробел для хаьрапарсера)
если, перед именем стоит знак @ то скрипт читает файл .bowerrc находит директорию где лежат модули, после знака @ идет имя модуля, и мы пытаемся прочитать файл bower.json в этом каталоге поле main.
Так же можно указать прямой путь к js файлу относительно корня проекта.
Единственное ограничение сторонние модули сейчас могут подключаться только в виде js файлов.
У меня другой подход, реализующийся через несколько самописных тасков для grunt`a
Весь проект делиться на маленькие модули, которые называются компоненты. Компоненты могут состоять как из js, так и из css или html шаблонов.
Структура компонента выглядит так:
имя папки(есть имя компонента) /
— /js — весь js код
— /style — стили
— /img — картинки
— /mock — моки
— /test — e2e и unti тесты
В дополнение к этому в корне компонента может быть файл c.json.
В котором могут быть указаны зависимости от других компонентов и/или структура компонента.
Имена компонентов «разруливаются» относительно директории исходников. Например:
Исходники у нас в папке src/client/
С такой структурой:
lib
— /utils
— /popup
— /button
— /icons
То " компонент утилиты" у меня будет называться lib.utils
Далее при разработке какого либо компонента который зависит от utils, я в файле c.json указываю «depends»: ['lib.utils']
Какие плюшки еще я получаю.
Я могу разрабатывать и тестировать компоненты отдельно от самого приложения, главное написать нужные зависимости, причем не важно, js это код или я пишу стили для кнопок.
Очень просто разруливаются зависимости.
Можно собирать несколько клиентов на одной кодобазе.
Не понимаю как это может помочь пользователям. Ну не будет доступа в консоль, ни чего не помешает, так же попросить ввести в адресную строку нечто вроде: javascript:, и этот код будет выполнен.
Но и это имхо слишком сложно для пользователя, куда проще, попросить добавить в закладки такую строчку, а потом просто кликнуть по ней на нужной странице. Вот примерно так: jsfiddle.net/q9atS/1/embedded/result/
Так что необходимость такой «защиты» весьма сомнительна.
По мне так SharowDOM это наоборот маст хев фича, с ее помощью, «без геморроя», можно будет кастомизировать стандартные представления. Зачем мне пилить свой плеер, если я могу подправить стили стандартного?
Судя по тестам, она в 10 раз быстрее Q
Там же есть сравнения с async.
github.com/petkaantonov/bluebird/blob/master/benchmark/stats/latest.md
Это напрямую связано с var, попробуйте написать без var и переменная будет объявлена в глобальном контексте.
пример:
foo.js
index.js
Почему так происходит? nodejs не делает магии, она просто оборачивает все модули в конструкцию вида:
Именно поэтому переменные объявленные через var видно только внутри модуля.
Так же следует помнить о том, что require возвращает поле exports объекта module, поэтому если мы хотим вернуть свой объект мы должны переопределять это поле.
если, перед именем стоит знак @ то скрипт читает файл .bowerrc находит директорию где лежат модули, после знака @ идет имя модуля, и мы пытаемся прочитать файл bower.json в этом каталоге поле main.
Так же можно указать прямой путь к js файлу относительно корня проекта.
Единственное ограничение сторонние модули сейчас могут подключаться только в виде js файлов.
Весь проект делиться на маленькие модули, которые называются компоненты. Компоненты могут состоять как из js, так и из css или html шаблонов.
Структура компонента выглядит так:
имя папки(есть имя компонента) /
— /js — весь js код
— /style — стили
— /img — картинки
— /mock — моки
— /test — e2e и unti тесты
В дополнение к этому в корне компонента может быть файл c.json.
В котором могут быть указаны зависимости от других компонентов и/или структура компонента.
Имена компонентов «разруливаются» относительно директории исходников. Например:
Исходники у нас в папке src/client/
С такой структурой:
lib
— /utils
— /popup
— /button
— /icons
То " компонент утилиты" у меня будет называться lib.utils
Далее при разработке какого либо компонента который зависит от utils, я в файле c.json указываю «depends»: ['lib.utils']
Какие плюшки еще я получаю.
Я могу разрабатывать и тестировать компоненты отдельно от самого приложения, главное написать нужные зависимости, причем не важно, js это код или я пишу стили для кнопок.
Очень просто разруливаются зависимости.
Можно собирать несколько клиентов на одной кодобазе.
Проверял в Chrome 30.0.1599.66
Но и это имхо слишком сложно для пользователя, куда проще, попросить добавить в закладки такую строчку, а потом просто кликнуть по ней на нужной странице. Вот примерно так: jsfiddle.net/q9atS/1/embedded/result/
Так что необходимость такой «защиты» весьма сомнительна.
ап. посмотрел видео, там о том же и говорят.