Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #1 (permalink)  
Старый 10.02.2017, 06:18
Аватар для spo
spo spo вне форума
Профессор
Отправить личное сообщение для spo Посмотреть профиль Найти все сообщения от spo
 
Регистрация: 11.05.2011
Сообщений: 213

Структура проекта для препроцессоров
Привет, всем.

Относительно недавно, решил расширить свои навыки, применением препроцессоров, систем автоматизации сборки проектов и других инструментов, уже давно переставших быть чем то новым в мире верстки и фронтенд разработки.

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

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

В русскоязычном сегменте интернета, существует не так много информации на эту тему. Вот что мне удалось найти:
В данных статьях относительно подробно все рассмотрено, но мне хотелось бы немного больше. А именно:
  • определиться, на какие составные части, в том или ином случае, разбивать структуру и оформление для html и css препроцессоров;
  • разобраться с внутренним устройством файлов (как, где и в каком порядке все это подключается и собирается);
  • а так же, вообще, лучше понять возможности и нюансы использования препроцессоров.

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

Последний раз редактировалось spo, 10.02.2017 в 06:35.
Ответить с цитированием
  #2 (permalink)  
Старый 01.03.2017, 15:58
Аватар для spo
spo spo вне форума
Профессор
Отправить личное сообщение для spo Посмотреть профиль Найти все сообщения от spo
 
Регистрация: 11.05.2011
Сообщений: 213

Определился со структурой.
Решил разбивать все максимально подробно. Не для каждого проекта это потребуется, но зато упростить потом смогу и сам, а вот с расширенной структурой есть ряд вопросов.

Начну со стилей.

Структура проекта в папке /source следующая:
  • /helpers
    • _reset
    • _vars
    • _mixins
    • _base
    • main - содержит @import _reset, _vars, _mixins, _base
  • /components
    • /nav
      • _media
      • styles - содержит @import _media
    • /page_home
      • /sidebar
        • _media
        • styles - содержит @import _media
  • /pages
    • home
      • _media
      • styles - содержит @import _media

'use strict';

const gulp = require('gulp')
	, sass = require('gulp-sass')
	, sourcemaps = require('gulp-sourcemaps')
	, concat = require('gulp-concat')
	, autoprefixer = require('gulp-autoprefixer')
	, cssnano = require('gulp-cssnano');

/* path */

const path = {
	styles: {
		source: {
			main: './source/helpers/main.sass',
			components: './source/components/**/*.sass',
			pages: './source/pages/**/*.sass'
		},
		build: './build/css/',
	}
}

/* tasks */

gulp.task('sass', function() {
	return gulp.src([path.styles.source.main, path.styles.source.components, path.styles.source.pages]) // Последовательность чтения и обработки (для конкатенации в определенном порядке)
		.pipe(sass()) // Компиляция кода препроцессоров
		.pipe(sourcemaps.init()) // Инициализация sourcemaps
			.pipe(autoprefixer({ // Обработка автопрефиксером
				browsers: ['last 3 version']
			}))
			.pipe(cssnano()) // Минимизация
			.pipe(concat('main.min.css')) // Конкатенация всех файлов в один
		.pipe(sourcemaps.write()) // Запись sourcemaps
		.pipe(gulp.dest(path.styles.build)); // Выгрузка в build-каталог
});


1. Из-за расширенной структуры, где стили расположены в разных местах, стоит задача объединить их в нужном порядке.
Для этого мне пришлось написать такой страшный path и gulp.src Нормальная ли это практика или есть более правильный способ?

2. Есть ли разница (например в производительности) в обработке файлов до конкатенации и после?

3. Нужно ли обрабатывать файлы js-плагинов (стили, скрипты) и объединять в основные файлы (build/css/main.min.css и build/js/scripts.min.css соответственно)? Если да, то как быть с файлами изображениями js-плагинов? Выгружать в build/img?

Последний раз редактировалось spo, 01.03.2017 в 16:03.
Ответить с цитированием
  #3 (permalink)  
Старый 01.03.2017, 18:18
Аватар для destus
Профессор
Отправить личное сообщение для destus Посмотреть профиль Найти все сообщения от destus
 
Регистрация: 18.05.2011
Сообщений: 1,207

1. А зачем стили подгружать в определенном порядке? Там где что-то конфликтует, можно разрешать через !important.
2. 3 маленьких бандла и 3 запроса на сервер или 1 большой файл и 1 запрос на сервер. Я выбираю второй вариант.
3. Нужно. И картинки тоже нужно прогонять через вспомогательные модули типа pngquant, которые пару кб тебе сэкономят. В идеале папка build должна форсироваться динамически, которую сразу можно выложить на продакшн.
Ответить с цитированием
  #4 (permalink)  
Старый 02.03.2017, 07:10
Аватар для spo
spo spo вне форума
Профессор
Отправить личное сообщение для spo Посмотреть профиль Найти все сообщения от spo
 
Регистрация: 11.05.2011
Сообщений: 213

Сообщение от destus Посмотреть сообщение
1. А зачем стили подгружать в определенном порядке? Там где что-то конфликтует, можно разрешать через !important.
Не совсем понял про !important.
А стили подгружать нужно в определенном порядке чтобы по порядку шли: reset, vars, mixins, base и далее все остальное

UPD: Кажется я вас понял вы имели ввиду @import а не !important
Я могу попросить вас перечитать мой вопрос или повторить его еще раз. У меня стили расположены в разных местах. В одном месте есть основной файл main который при помощи @import собирает reset base итп. В других местах содержаться другие стили, например components/nav/styles.sass содержит стили а так же @import _media Таким образом при компиляции sass я получаю множество файлов стилей в разных местах. Вот эти файлы затем я и конкатенирую и на этом шаге мне важна их последовательность. Наверное можно все файлы стилей компонентов вручную при помощи @import вставлять в основной файл, но зачем если можно автоматизировать.

Сообщение от destus Посмотреть сообщение
2. 3 маленьких бандла и 3 запроса на сервер или 1 большой файл и 1 запрос на сервер. Я выбираю второй вариант.
Тоже не совсем понял, о каких запросах на сервер идет речь? Файл в обоих вариантах будет один. А мой вопрос про обработку стилей плагинами. Вначале собрать в файл а потом обрабатывать или обработать на лету а потом собрать в файл.

Сообщение от destus Посмотреть сообщение
3. Нужно. И картинки тоже нужно прогонять через вспомогательные модули типа pngquant, которые пару кб тебе сэкономят. В идеале папка build должна форсироваться динамически, которую сразу можно выложить на продакшн.
Как бы не совсем то что я спрашивал. Мой вопрос в том нужно ли файлы модуля js (стили, скрипты, картинки) обрабатывать и раскидывать по папкам в build

Последний раз редактировалось spo, 02.03.2017 в 20:57.
Ответить с цитированием
  #5 (permalink)  
Старый 02.03.2017, 20:58
Аватар для spo
spo spo вне форума
Профессор
Отправить личное сообщение для spo Посмотреть профиль Найти все сообщения от spo
 
Регистрация: 11.05.2011
Сообщений: 213

Товарищи, пожалуйста подскажите.
Ответить с цитированием
  #6 (permalink)  
Старый 03.03.2017, 08:36
Аватар для destus
Профессор
Отправить личное сообщение для destus Посмотреть профиль Найти все сообщения от destus
 
Регистрация: 18.05.2011
Сообщений: 1,207

Цитата:
Наверное можно все файлы стилей компонентов вручную при помощи @import вставлять в основной файл.
Именно так я бы и делал. Но если вы хотите нужный порядок в gulp.src, указывать, то никто не запрещает. Так делать можно. Я бы не рекомендовал использовать имя переменной "path", потому что есть Node.js модуль path (кстати, странно что вы его не используете), и лучше этой переменной объявлять объект, который он экспортирует
const path = require('path');
const projectPath= {
	...
}
...

Цитата:
А мой вопрос про обработку стилей плагинами. Вначале собрать в файл а потом обрабатывать или обработать на лету а потом собрать в файл.
Обработать на лету, а потом собрать в файл и минимизировать. Потому что до concat, у тебя будут выходить из потоков разные файлы, concat их будет все ждать и потом объединять. И там будет параллелизм, то есть не просто сначала найти все файлы в gulp.src и обработать плагинами, а всё вперемешку.

Цитата:
Нужно ли обрабатывать файлы js-плагинов (стили, скрипты)
Обычно с библиотекой/плагином уже идёт минифицированный/сжатый файл и как-то обрабатывать его не нужно дополнительно.
Цитата:
объединять в основные файлы (build/css/main.min.css и build/js/scripts.min.css соответственно)?
Часто то что написано не нами, объединяют в отдельный файл (vendor), а то что нами в свой (main, app, ...). Это хорошо для кэширования на клиенте. Ну то есть твоё приложение каждую неделю, например, получает новую версию, ты его выкладываешь и юзеры скачивают обновленный код (кстати, где gulp-rev плагин для "умного" кэширования? http://javascript.ru/optimize/cache-...ie-versionnost ). А vendor меняется редко и постоянно будет браться из кэша.
Цитата:
то как быть с файлами изображениями js-плагинов? Выгружать в build/img?
да (gulp-css-url-adjuster)

Последний раз редактировалось destus, 03.03.2017 в 08:53.
Ответить с цитированием
  #7 (permalink)  
Старый 03.03.2017, 12:52
Аватар для spo
spo spo вне форума
Профессор
Отправить личное сообщение для spo Посмотреть профиль Найти все сообщения от spo
 
Регистрация: 11.05.2011
Сообщений: 213

destus, большое спасибо!
Ответить с цитированием
Ответ


Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
SEOCRM - бесплатные инструменты для оптимизаторов, интернет-маркетологов и владельце SeoCRM Оффтопик 0 23.05.2016 11:59
Требуется программист на QML для создания интерфейса клиентской программы для общения m.simakov Работа 0 11.02.2016 18:07
Webpack.config для сборки проекта и компиляции less karssen Сборка проекта, утилиты 2 30.01.2016 19:22
Как расшифровать JS для imacros и валидность и структура? Помогите!!! infobizon Firefox/Mozilla 0 14.11.2015 14:14