deekhalden/pagespeed

pagespeed's Issues

Наследование и импорты Pug/Jade

Наследование лучше include.

Пример:
Есть шаблон страницы. Мы его наверстали. Все классно. Но такое вот дело.

html
  body
    header
      row
        cell Logo text
        cell
          include menu.pug

    article
      h1 Page title
      p page content

Все шло хорошо, но добавилась еще одна страница. где меню/заголовок должно выглядеть иначе.

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

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

Немного про Git

При работе над проектом всегда держим его на гите.
https://habrahabr.ru/post/106912/ - Очень хороший вариант построения процесса разработки. Но если просто будет dev и master ветки - то уже неплохо.

В git храним исходники в первую очередь, файлы описания проекта, конфигурационные. Файлы билда - редко но иногда может понадобиться.

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

Переезжаем на Stylus

http://stylus-lang.com/
Быстро и мало писать код на sass, а тем более scss попросту невозможно.
Mixins/functions - ад кромешный в плане синтаксиса. А это основной инструмент, если мы не хотим увязнуть в куче кода, исправлять который можно только заплатками с !important.

BEM

Это не БЕМ.

// partials/equipment__wrapper.scss
.heading_wrapper {
    h2 {
        a.styled {
            ...
        }
    }
}

Стилизация тегов подходит для работы над проектами не сложнее Hello World. Разрастание подобного кода - сплошные заплатки повсюду.

В требованиях БЕМ указан не для просто так. Делая исходя из спецификации мы получаем поддерживаемую, легко расширяемую кодовую базу. И если проект !вдруг(!вдруг - это любимейший прием заказчиков) вырастает из лендинга в приложение для мониторинга загруженностью отелем, с бронями, отправкой уборщиц, построением расписаний работы служб, то нужно переписывать существующие стили, или лепить франкенштейна(кто-ж тебе даст переписывать стили? у менеджера время на это в бюджете не заложено, да и вот-же они, на лендинге уже есть, родимые...)

Не надо

Прям исправлять, прям по всем пунктам что тут даны - нет, не нужно.
Это написано на будущее.

Код в целом(немного съехал в Jade/Pug)

1. Табы/Пробелы. Используем только что-то одно.
2. Отступ "внутрь" - это всегда единичная "идентация". Несколько раз табнул и так оставил - ляп себе по руке. Это как проблема чисто эстетическая, так и для компилятора/интерпретатора может быть неявной на каком уровне что находится. Некоторые языки не обрывают компиляцию при разном уровне отступов в коде. Даже если переварил - не значит что переварил правильно. + потом для выравнивания нужно тоже будет делать больше табов чем положено.
3. Mixins. По одной примеси на файл выносить вредно для душевной организации. Представим 15 штук примесей, которые нам нужны, которые находятся на разных уровнях вложенности - это ад с ../../../../ в инклудах. Группируем примеси по их функции и выносим в отдельный файл. Сильно много набралось - делим на файле еще более специфично группируем в папочку, делаем там index.pug в котором это все дело includ'им и счастье со всего одним(двумя-4'мя) include.
4. Выносить наружу(для дальнейшего include) имеет смысл только что-то более-менее значительное. Подзаголовок(см. код1) в отдельном файле нам не нужен, скорее всего это должен быт быть mixin.
5. Все группируем по папочкам. Файл component__element--with-modifer--and-yet-another.pug - не ок. Практика группирования дисциплинирует, и заставляет больше думать над организацией кода.
6. Эмулировать работу системы управления не нужно. Тоесть контент можно определить 1 раз. И просто вставлять его 20 раз подряд в шаблон превьюшки товара(например). Если есть разные состояния элементов - рандом, или оперируем остатком от целочисленного деления итератора на константу.

Код1.

include subheading
.container-fluid.heading_wrapper
	.row
		+CreateSubheading('Оборудование', 'Скачать прайс', '/', 'a')

По визуалу(а получилось по коду как всегда)

1. http://joxi.ru/KAxXbzXH5N3vA8 - В а блочным элементам не место(по спецификации)(тоесть нужен span). Верстка ломается от браузера к браузеру.
2. Flex - круто, но либо магия с float никуда не делась и вполне работает, просто более страшненько и не все ее огрехи чистим, либо делаем mobile-first(чего нет, того нет). Но первое все-же предпочтительнее, если у заказчика явно не > IE 11. И даже для него нужно помнить об особенностях: см. Known issues
3. http://joxi.ru/DmB4zN4tLbwBAP - Картинки не должны деформироваться. Обрезаться - да, можно.
4. Mobile-first. Так мы говорим IE8 и ниже, что они устарели, и могут потреблять максимум мобильный контент. Еще один плюс - для мобилок легко подключать только им нужные стили. Еще один плюс - эволюционный ход написания кода(от хиленького к перегруженного анимациями). Еще один плюс... Из минусов более высокая сложность(но костылей можно приделать в любой момент если уж сильно прижмет)
5. Странная структура скриптов. Например googleMap есть в двух местах. Какой из них будет в итоговом бандле? В какой последовательности будет вызван? Какая из initMap все-таки будет в window и какую перезапишут? То-же и к другим относится. Вендоры тоже в двух экземплярах...