Good style по фронту

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

Какие проекты могут быть и из чего может состоять набор фронтенд разработчика?

Функционал конечно везде требуется разный, где-то вообще никому не нужен ваш package.json, и установка nodejs для запуска gulp команды это что-то из области фантастики, а где-то без системы сборки совсем невозможно жить. Иногда нужен просто index.html, а иногда полноценное SPA.

HTML\TWIG

В качестве шаблонизатора, я предпочитаю TWIG, он отлично дружит с Marionette js, Symfony и Yii. Какие-то маленькие и динамические элементы можно и на JS сделать с помощю document.createElement(). Массовую сборку большого количества статичных типичных файлов собираю через consolidate.

Советы по симфони

1. Все ссылки внутри шаблонов, должны быть указаны через функцию path
   Плохо

   <a href="http://…..">ссылка</a>
   

   Хорошо
   
   <a href="path("routename")”>ссылка</a>

2. Ссылки на изображения должны быть переданы в src атрибут с помощью функции asset(). Так есть функция asset_if_exists, которая принимает два параметра: первый — сам ассет, второй — урл ассета-заглушки если искомый ассет не найден (только на shakes.im)
3. В разметке следует каждый новый элемент ставить с новой строки
   Плохо
   

   
   <div class="header"><p><i class="icon icon-header></i>header text</p></div>

   
   Хорошо
   

   
   <div class="header">
    <p>
    <i class="icon icon-header></i>
    header text
    </p>
   </div>

4. При использовании TWIG блок {% extends %} всегда пишется на первой строке и отделяется пустой строкой от остальных блоков.
5. На продакшн не должны попадать комментарии и различные “временные/тестовые” блоки.

JS

1. За каждый view должен отвечать 1 js файл. Файл внутри должен иметь свою область видимости и по возможности сводить к минимуму использование глобальных переменных, для избежания конфликтов.
   Плохо
   

   function funcName() {
   …
   }

   
   Хорошо
   

   (function(){
    var funcName = function () { … };
   })();

2. Для корректной передачи данных в твиг, не стоит писать весь js в твиге, необходимо только передать нужные переменные после подгрузки скрипта.
   Пример:
   

   {% if is_granted('ROLE_ADMIN') %}

          <script type='text/javascript'>
            $(function(){
                shakes.adminAjaxUrl = '{{ path('a_switch_user') }}';
            });
            </script>
            <script src="{{ asset('bundles/app/js/admin_login.js') }}"></script>
        {% endif %} 

Стоит обратить внимание на то, что переменная передается не в глобальный объект window а в зарезервированный объект shakes доступный на всех страницах сайта 

1. Обязательно использовать strict mode, для избежания множества ошибок. Подробнее читать тут.
2. JS библиотеки необходимо отделять от самописных js файлов в папку lib
3. При навешивании обработчиков на какие-либо элементы, рекомендуется добавить отдельный класс для этого с префиксом js прим. js-submit-form
4. При работе с динамическим состоянием элементов на js в форме и интерфейсе, обязательно пересчитывать и поддерживать актуальным состояние “модели” данных при любых действиях. Перед сабмитом формы, также программно проверять состояние модели, а также прогонять кейсы с движением пользователя “вперед/назад” в браузере с кешированием.

ES2015 (ES6)

На момент написания статьи, новый стандарт JavaScript “как-бы” уже можно лицезреть во всех новомодных браузерах, но вам лучше познакомиться с Babel и npm вам в этом поможет. на данный момент. JS разработчикам обязательно уже сейчас необходимо привычно обращаться со стрелочными функциями, а также стилистикой let, const, class, уметь ответить на вопросы о замыканиях, передаче контекста, промисах и etc…

CSS

1. Предпочтительна методология БЭМ. Все классы элементов должны быть названы по принципу (блок)__(название_елемента)-(модификатор)
2. Для удобства все иконки следует выносить в файлы icons.css или пользоваться сборщиком спрайтов gulp. Я использую gulp-iconfont
3. Максимально избегать каскадных правил в CSS — придерживаться правила 1 элемент = 1 селектор.
4. Четко понимать разницу между HTML4 и HTML5 и понимать семантику языков.

Организация фронтенд архитектуры

1. В production должны попадать только минифицированные и обработанные css файлы. Для сборки фронта используется Gulp.
2. Чтобы не запоминать всем участникам команды. различные gulp команды, конфиг gulp’a должен быть настроен с командой build, которая в необходимой очередности запускае все необходимые задачи.

буду пополнять и обновлять список по мере поступления идей и обратной связи от вас)