Комментарии 38
Эм… angular-seed + require.js? А где все что нужно для прогона unit/e2e? где протрактор? Мне больше нравится ngboilerplate. Правда в итоге я все-равно собрал для себя свой скелет проекта.
p.s. require.js на самом деле не так уж и нужен для проектов на angular.js. Зависимости разруливаются внутри фреймворка, так что главное правильно собрать проект, а для этого хватит и связки concat+ngmin+uglify.
p.s. require.js на самом деле не так уж и нужен для проектов на angular.js. Зависимости разруливаются внутри фреймворка, так что главное правильно собрать проект, а для этого хватит и связки concat+ngmin+uglify.
Правда в итоге я все-равно собрал для себя свой скелет проекта.
Так не стесняйтесь же, поделитесь.
А про тестирование — тут каждый по-своему решает, хотя, конечно, можно и протрактор предложить.
Расскажите как смогли с ng-min подружиться? Он же ни черта не оптимизирует в сложных ситуациях, например, контроллеры директив и т.п.
По моему опыту надо выносить все составные части проекта в отдельные файлы. Часто приходится использовать еще и вложенные папки, для лучшей структуры. Проект при этом билдится с помощью grunt в реальном времени.
Не то что в отдельные файлы, но и в отдельные модули.
Если это модули или какие-то самописные плагины, то я лично для этого использую ту же lib папку.
Каждый отдельный контроллер, сервис и т.д. следует выносить в отдельный файл. При этом, еще лучше, как написал Fesor разносить архитектуру на отдельные модули.
Почему следует? Сам так делал и кроме головной боли при постоянном переключении между файлами ничего из такого подхода не вынес.
Я думаю что если у вас часто возникает необходимость вносить изменения за раз сразу в паре десятков файлов, то что-то явно пошло не так. Либо же вы не работали с большими приложениями.
в паре десятков? аппокалипсис, определенно. Мне лично достаточно попрыгать хотя бы между двумя файлами, чтобы предпочесть это скролу в одном.
Каждому свое. Я обычно разве что фильтры пишу в одном файле, и то не все а скажем, для модуля. Или небольшие директивы, которые можно объединить по смыслу. Одно дело переключаться между файлами в период разработки (у меня редко бывают случае когда нужно переключаться больше чем между тремя файлами), и искать какую-то директиву при новой итерации, особенно когда ее писал кто-то другой, и это было год назад.
Почему следует?
Потому что это хрестоматийная истина, 90% файлов должно умещаться на один экран. Попробую объяснить почему:
1. если вы работаете в команде, то все будут работать в одном огромном файле, что плохо скажется на сливании и комитах.
2. если вам нужно внести правки в код, то не придется скролить в 2600 строке. Достаточно набрать в IDE имя нужного файла.
3. нет структуры кода, невозможно понять какой класс/функция какому модулю принадлежат.
Да вот практика показала, что ничего страшного в этом нет. Раньше рассуждал так же, как и вы.
Конфликт при мердже будет конфликтом вне зависимости от того, в каком файле он произойдет.
Аналогично вбиваете имя класса и перескакиваете к нему, при этом не нужно прыгать в панель файлов проекта.
По-моему это немного не в тему. Мы ведь не про структурирование на модули говорим, а про то, как писать компоненты вгутри одного.
Давайте я закрою этот вопрос. Я лично пробовал делать обоими способами. Причем изначально был сторонником вашей позиции. И существенной разницы не почувствовал. Меня смутил безаппеляционный тон, поэтому я захотел услышать аргументы. Аргументы оказались чисто субъективными и объективных причин говорить, как «следует» делать, я так и не увидел.
1. если вы работаете в команде, то все будут работать в одном огромном файле, что плохо скажется на сливании и комитах.
Конфликт при мердже будет конфликтом вне зависимости от того, в каком файле он произойдет.
2. если вам нужно внести правки в код, то не придется скролить в 2600 строке. Достаточно набрать в IDE имя нужного файла.
Аналогично вбиваете имя класса и перескакиваете к нему, при этом не нужно прыгать в панель файлов проекта.
3. нет структуры кода, невозможно понять какой класс/функция какому модулю принадлежат.
По-моему это немного не в тему. Мы ведь не про структурирование на модули говорим, а про то, как писать компоненты вгутри одного.
Давайте я закрою этот вопрос. Я лично пробовал делать обоими способами. Причем изначально был сторонником вашей позиции. И существенной разницы не почувствовал. Меня смутил безаппеляционный тон, поэтому я захотел услышать аргументы. Аргументы оказались чисто субъективными и объективных причин говорить, как «следует» делать, я так и не увидел.
Посмотрите на структуру крупных open source проектов и подумайте почему «бородатые дяди» не пишут все в одном файле, пусть даже в рамках одного модуля.
Если для вас это удобно, то пользуйтесь огромными файлами. Но когда вы будете работать над крупными проектами вы поменяете свою точку зрения, или ваши коллеги вам ее поменяют.
И существенной разницы не почувствовал.
Если для вас это удобно, то пользуйтесь огромными файлами. Но когда вы будете работать над крупными проектами вы поменяете свою точку зрения, или ваши коллеги вам ее поменяют.
Это все на самом деле довольно субъективно. Мне к примеру проще переключить в IDE файл, чем скролить. Ну и позиция курсора в открытых файлах сохраняется, меньше перемещать. Опять же можно держать на одном экране открытыми несолько файлов, что бы перед глазами было все что нужно.
кто-нибудь может объяснить какое преимущество в angular.js?
и чем он лучше knockout.js?
и чем он лучше knockout.js?
Иногда мне кажется, что, главным образом, в том, что angular получил серьезную пиар поддержку на старте. Сайты успешно делают и на том, и на другом. Каждый выбирает либо то, чем он лучше владеет, либо если не владеет ни тем, ни другим, то, о чем больше всего говорят. Сейчас мне кажется, что в Angular более четкая логика разделения модуля на контроллеры, сервисы и директивы, но не исключаю, что это только потому, что все последние проекты я делал на Angular, а не Knockout
knockout.js — библиотека для data binding и все, а angular это MVVM фреймворк. Только на knockout сложное приложение не сделаешь, всеравно нужны будут jquery, underscore/lodash, для разделения логики и представления backbone или что-то еще… А angular самодостаточен, хорошо структурирован и с ним ваш код легко покрывать тестами.
Yeoman angular, angular-require.
А в чем фишка yoman? Просто в свое время, когда я для каждого контроллера, сервиса и т.д. создавал отдельный файл, мне было достаточно шаблонов в Webstorm для соответствующих элементов. Я правильно понимаю, что по функционалу это тоже самое?
Да, вот только в команде разработчики могут сидеть хоть на Webstorm, хоть на vim.
Суб-генераторы для контроллеров, views, сервисов, factories. Заготовки тестов для всего вышеперечисленного. LiveReload из коробки. По необходимости можно включить поддержку bootstrap, SASS. Вебсервер на Node.js из коробки. Bower из коробки. Настроеный gitignore чтобы не тащить в репо, что не надо.
Сегодня разворачивали новый проект на машине второго разработчика — git clone, npm install, bower install, grunt serve. Через 2 минуты имеем полностью настроенное рабочее окружение.
Мне для того чтобы всё сделать руками — понадобится намного больше времени, но кроме всего прочего, лучшие профессионалы уже подумали и сделали — только пользуйся. А если захочется большего — есть генератор генераторов.
Сегодня разворачивали новый проект на машине второго разработчика — git clone, npm install, bower install, grunt serve. Через 2 минуты имеем полностью настроенное рабочее окружение.
Мне для того чтобы всё сделать руками — понадобится намного больше времени, но кроме всего прочего, лучшие профессионалы уже подумали и сделали — только пользуйся. А если захочется большего — есть генератор генераторов.
У меня другой подход, реализующийся через несколько самописных тасков для 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 это код или я пишу стили для кнопок.
Очень просто разруливаются зависимости.
Можно собирать несколько клиентов на одной кодобазе.
Весь проект делиться на маленькие модули, которые называются компоненты. Компоненты могут состоять как из 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 это код или я пишу стили для кнопок.
Очень просто разруливаются зависимости.
Можно собирать несколько клиентов на одной кодобазе.
Спасибо, буду признателен и, думаю, люди тоже, если вы поделитесь своими тасками =) Еще такой вопрос — как при такой системе подключаются сторонние библиотеки?
сторонние библиотеки устанавливаются через bower и указываются в c.json. Например для указания зависимости от angulara в c.json добавляем «bower»: ['@ angular'] (пробел для хаьрапарсера)
если, перед именем стоит знак @ то скрипт читает файл .bowerrc находит директорию где лежат модули, после знака @ идет имя модуля, и мы пытаемся прочитать файл bower.json в этом каталоге поле main.
Так же можно указать прямой путь к js файлу относительно корня проекта.
Единственное ограничение сторонние модули сейчас могут подключаться только в виде js файлов.
если, перед именем стоит знак @ то скрипт читает файл .bowerrc находит директорию где лежат модули, после знака @ идет имя модуля, и мы пытаемся прочитать файл bower.json в этом каталоге поле main.
Так же можно указать прямой путь к js файлу относительно корня проекта.
Единственное ограничение сторонние модули сейчас могут подключаться только в виде js файлов.
У меня была как-то идея организовать схожую систему сборки, но без json с зависимостями, но увы руки так и не дошли. Точнее я думал вооружиться astral (по аналогии с ngmin) и таким образом разруливать зависимости, а все внешние зависимости, типа underscore и jquery забирать уже из index.html и добавлять туда при сборке правильные ссылки (с указанием CDN при сборке в релиз).
Хочу поделиться своей наработкой: AngularJS + gulp
В пакет входит: gulp-uglify, gulp-jshint, gulp-concat, gulp-sass, gulp-jade, livereload и еще пара модулей.
github.com/tundrax/angular-gulp/
В пакет входит: gulp-uglify, gulp-jshint, gulp-concat, gulp-sass, gulp-jade, livereload и еще пара модулей.
github.com/tundrax/angular-gulp/
Запуск сервера разработки
Билд
Файлы конфигурации среды (development, staging, production) находятся в папке src/scripts/config
Тест
gulp --env=development или gulp --env=stagingБилд
gulp build --env=productionФайлы конфигурации среды (development, staging, production) находятся в папке src/scripts/config
Тест
карма стартА как вы решили проблему, при которой, допустим при выполнении gulp-sass, в случае если у нас ватчер запустил сборку и она упала (синтаскическая ошибка или еще чего), падает и ватчер?
Итак, главное, что нам дает require.js, помимо модульности
Где в Вашем проекте модульность? Все контроллеры, сервисы, директивы свалены в одну кучу. Все модули подключаются к главному, без иерархии.
— возможность свести всё приложение в один файл и затем сжать.
Это к гранту вопросы (Вопрос №1, Вопрос №2).
Общая структура проекта не должна вызывать особых вопросов.
Конечно не вызывает, это же обрезанный Angular Seed. А вот вопросы начнут появляться, когда приложение начнет разрастаться, понадобиться упомянутая выше модульность.
app.run(controllers.GlobalCtrl);
Зачем контроллер-то в .run запускать? Для это есть сервисы (нативные, без извращения require.js).
Или
<html ng-app="App" ng-controller="indexCtrl"> — будет запущен только раз, когда приложение загрузилось.Советую внимательно посмотреть на ngbp и все будет хорошо.
Я думаю, вы могли бы оформить ваш код в виде yeoman генератора, это позволит разворачивать «скелет» приложения в 2 команды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Angular boilerplate. Простота — тренд молодежи