Структурирование узла.приложение js и AngularJS

Question

Структурирование узла.приложение js и AngularJS

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

первое, что я пытаюсь понять, это хорошая структура файлов. До сих пор мой чистый шаблон HTML/CSS имеет следующую структуру каталогов...

_site/
Fonts/
Javascript/
SASS/
Stylesheets/
Index.html

(_site-это рабочий каталог для PSDs и др.)

Я нашел пример структуры каталогов для узла.JS / AngularJS app здесь....

... что предполагает следующую структуру каталогов.

app.js              --> Application configuration
package.json        --> For npm
public/             --> All of the files to be used in on the client side
  css/              --> CSS files
    app.css         --> Default stylesheet
  img/              --> Image files
  js/               --> JavaScript files
    app.js          --> Declare top-level application module
    controllers.js  --> Application controllers
    directives.js   --> Custom AngularJS directives
    filters.js      --> Custom AngularJS  filters
    services.js     --> Custom AngularJS services
    lib/            --> AngularJS  and third-party JavaScript libraries
      angular/
        angular.js            --> The latest AngularJS
        angular.min.js        --> The latest minified AngularJS
        angular-*.js          --> AngularJS add-on modules
        version.txt           --> Version number
routes/
  api.js            --> Route for serving JSON
  index.js          --> Route for serving HTML pages and partials
views/
  index.jade        --> Main page for the application
  layout.jade       --> Doctype, title, head boilerplate
  partials/         --> AngularJS view partials (partial jade templates)
    partial1.jade
    partial2.jade

Так что, это выглядит довольно хорошо для меня (за исключением того, что я бы не использовал нефрит).

у меня еще есть следующие вопросы...

Я хочу, чтобы все интерфейсные и фоновые файлы были разделены. Это решение помещает все интерфейсные файлы в общедоступный / каталог, что имеет смысл, потому что большинство из них нужно будьте общедоступны, но имеет ли смысл размещать здесь папки SASS и _site? Я мог бы просто держать их там, но не загружать их, когда я положил их в производство, но это кажется неправильным, потому что они не должны быть публичными. Они также не принадлежат на корневом уровне со всеми внутренними вещами.
не лучше ли загрузить AngularJS из CDN?
учитывая, что сервер должен будет доставить только один шаблон (основное приложение template) и все остальные HTML будут построены на интерфейсе, не было бы больше смысла сохранять индекс.HTML-файл статический, удалите папку views и создайте partials / папку в разделе public/, как это делает оригинальное приложение AngularJS Seed?

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

6 77

javascript node.js angularjs

6 ответов:

со временем все становится проще. Я использовал Yeoman для AngularJS front-end, и это делает жизнь намного проще:http://yeoman.io/

Вариант 1, MEAN.io

MEAN-это потрясающая аббревиатура! Я предпочитаю среднюю структуру каталогов стека. Давайте использовать людей конвенции! Просто используйте структуру каталогов изmean.io. MEAN тоже удобен, потому что он бросает все лакомства, такие как грунт, беседке и т. д.

Вариант 2, угловой-семя + Экспресс.js

я искал GitHub для узла.проекты js/AngularJS (вероятно, недостаточно жесткие) и не видели ничего действительно хорошего для начальной структуры каталогов. Поэтому я объединил узел.JS Express.в JS (под управлением Экспресс.js из командной строки не используя ни один EJS, ни Джейд/Мопс) скелет с проектом углового семени (клонировать его с GitHub). Потом я перевезла кучу вещей. Вот что я придумал:

developer - материал будет использовать только разработчик(ы). Не требует развертывания.

config - файлы конфигурации кармы и другие.

scripts - скрипты разработчика (сборка, тестирование и развертывание)

test - Е2Е и модульные тесты.

logs

node_modules - этот ответ переполнения стека рекомендуется поместить это в Git. однако теперь это может быть устаревшим.

public - это происходит почти прямо из папки приложения angular-seed.

css,img,js,lib,partials - довольно очевидно и красиво и коротко.

routes - узла.Яш маршруты.

server - серверный узел "shebang".программы на JS, управляющие программы, программы хрон , что угодно.

server.js - переименован из приложения.js просто, чтобы сделать его более очевидным, это серверная сторона.

36

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

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

вы также можете рассмотреть вопрос о просмотре старшина для создания скелета проекта.

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

Это отличный инструмент для загрузки и управления проектами (аналогично Rails делает) и создаст структуру каталогов и скелетные файлы для вас, чтобы построить на них. Брайан Форд написал отличный пост при использовании Йомена с угловым.

Я также предлагаю смотреть угловые записи meetup на своем канале YouTube. Недавно я присутствовал на встрече в Маунтин-Вью, где возникли эти вопросы. Мишко рекомендовал Угловое семя и Йомена (по крайней мере, как хорошую отправную точку.)

чтобы ответить на ваш индивидуальный вопросы:

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

всегда хорошо обслуживать статические активы (JS, изображения, CSS) из a CDN, если вы ожидаете большой объем трафика. Это не так важно для менее посещаемых сайты, но все же хорошая идея. Я бы начал с локальное обслуживание файлов для начальной разработки. Оставить актив оптимизация для того, когда вы приближаетесь к своей живой дате. Когда это пришло время, когда вы также захотите правильно настроить свое кэширование. Йомен, например, представляет собой хороший способ управления версиями ваших активов. Это дает вам преимущество долгоживущих тайников, но позволяет вам чтобы отправить обновления файлов клиентам.

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

действительно, вам просто нужно поиграть; попробовать разные вещи, читать сообщения в блоге, получать идеи от других, задавать вопросы (как вы сделали здесь, так и на угловом Google+ страница сообщества), смотреть видео и, если вы можете, посещать meetups - Meetups действительно отлично подходит для этого.

5

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

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

лучше поместить свой бэкэнд-код в каталог типа "сервер" на том же уровне папок, что и "css", "image"... Преимущество этого заключается в том, что когда вам нужен или не нужен бэкэнд, просто добавьте или удалите каталог "сервер", и это не повлияет на структуру исходного проекта.

такой:

2

я расследовал то же самое.

мои первоначальные мысли были направлены на использование Экспресс-Генератора и Угловое Семян.

тогда я нашел гораздо более приятное решение:

http://yeoman.io/

http://yeoman.io/generators/

(один из самых популярных генераторов) https://github.com/angular-fullstack/generator-angular-fullstack

один из самых популярных йомен генераторы предоставляет вам структуру узла.приложения js и AngularJS.

Я верю в силу стандартизации, и новые люди, присоединившиеся к проекту, оценят единую структуру.

0

посмотреть этот скелет

https://github.com/Giancarlo1974/SailsAngular

Это интегрирует Angular 4 + Bootstrap 4 для клиента и узла Sails JS для сервера

одна из сильных сторон этого решения: 1) Задач Автоматизации 2) База Данных Агностицизм

0

Olivier · Accepted Answer · 2014-01-19 18:00:11

1) обычно имеет смысл сделать saas/less файлы общедоступные, поскольку вы можете использовать меньше на стороне клиента->преобразование css при отладке (меньше.js делает это). Не уверен, что ваш содержит (кстати, вы должны использовать папку в нижнем регистре для вашего проекта, особенно для общественных вещей).

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

3) Даже если рендеринг на стороне клиента-это путь, вы можете сохранить рендеринг на стороне сервера/представления, вам, вероятно, понадобится это в какой-то момент (доступ администратора, рендеринг электронной почты и т. д.). Однако это может быть полезно использовать partials имя из AngularJS в общей папке, чтобы избежать путаницы между серверной стороной views & на стороне клиента partials.

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

вы должны проверить существующие express framework, чтобы увидеть, как они структурируют свое приложение. Например, TowerJS имеет довольно чистый!--5--> папка, однако они смешивают серверный и клиентский код, который мне лично не нравится.

проверьте это сравнение NodeJS MVC Framework чтобы увидеть, как другие делают вещи. Тем не менее, я бы явно начал с ванили экспресс-код для того, чтобы быть в полном контроле и понять, как все работает, прежде чем чрезмерно фиксировать на любой из этих фреймворков.