Поговорим о том, что вы и так уже знаете.
Это моя первая статья на Хабре и я не писатель. Но взглянув на Фронтенд-2018: итоги года, руки потянулись в sublime и начали писать.
Любая сложная задача состоит из простых. Умение правильно делать декомпозицию — необходимость.
Буду вести рассуждение на примере большинства проектов из личного опыта.
Уверен, вы скажете "А у нас не так и вообще react это быстро, логично и читабельно, генерировать стили при помощи js — не какая-то там надстройка, это модно, а фронтендщики не нужны, ибо наш бэкендщик Феофан сделал отличную форму на php", но все же.
Обозначение
Г1. Гении, которые это могут, являются исключениями, частным великолепный случаем.
М*. Мысль
Это можно не читать
Итак, начнем!
М1. Дубляж кода это плохо.
М2. Всегда надо думать на 100 шагов вперед.
Например, на старте проекта берем в расчет его состояние лет через 5.
Очевидно, запуская социальную сеть сразу можем сказать, что помимо веб версии будут мобильные приложения, десктоптные приложения. Отсюда…
М3. Серверная часть должна писаться только один раз. (М1)
А так как у нас есть веб версия, мобильная, десктопная, то…
М4. Серверная часть занимается данными.
Серверная часть не должна решать, какую кнопку нарисовать и какого цвета она должна быть.
Шаблон письма или html файл, который [может] подгружается при загрузке страницы для индексации поисковиком — это тоже работа с данными. Увы там приходится манипулировать html (из-за требований к индексации, например), но это уже другая проблема.
Фактически можно было бы передавать первоначальный набор файлов (html, js, css) и данные. Т.е. и тут бэк не занимается версткой.
Вот тут произошло первое разбиение проекта: откололась серверная часть. Я не буду рассуждать на каком языке написана, как устроена архитектура (добрым словом поминаю MVC). Это не мое дело ибо…
М5. Каждый должен заниматься своим делом
Фуллстеки покрывают какую-то часть проектов и тут с этим пунктом вы можете и будете конечно спорить, но обращаясь к (М2) моя позиция тут сформирована: дешевле иметь двух профессионалов своего дела, чем переписывать проект через год. Разумеется есть гении (Г1), которые поспевают везде, но таких единицы, а значит нельзя их брать в рассуждениях «Как должно быть».
Я так же отколю от этого пирога ветку Дизайнера, Юзабилиста и ко.
Поймите правильно, нормальный фронтендщик может самостоятельно накидать макет «верстая», ориентируясь на миллион аналогов и свою фантазию, но мы же по (М2) говорим о серьезных проектах, так что не льстите себе :) (Г1)
Отлично, у нас есть данные (api, все нужные методы итд итп.), у нас есть макеты — и начнем.
В виду современных реалий — я ввел бы еще одно разветвление. Увы и ах, но огромная доля современных фронтендщиков либо не умеют работать с версткой, либо не знают js. Я провел огромное количество собеседований и это странно наблюдать. По этому фронтов можно разделить на «верстальщиков» и «неверстальщиков??».
М6. Разработка должна вестись больше чем в одном файле
Скажете очевидно? Да, очевидно!
М7. Фронт делится на 2 части: та, что работает с данными, и та что их отображает.
У нас может отсутствовать та или иная часть. Например: быть только отображение (статическая страница) или быть только данные (скрипт в консоли и т.д.).
Тут предлагаю абстрагироваться и представить: вы человек-пиццерия. Принимаете звонки, раскладываете красиво сыр и отвозите покупателю. Логика подсказывает, что вы не особо эффективны (М1). Но если с вами работало бы еще 2 человек то было бы куда круче! Один принимает звонки (работает с данными), второй отвозит (представление), третий раскладывает сыр красиво :) (стилизация представления)
Уже слышу «КЭП» из 2012, «очевидно», но давайте еще раз…
М8. JS — это работа с данными.
Звонит бэкенду, принимает заказ и ему абсолютно все равно, как там уложен сыр. Может пиццы и вовсе не существует, может он просто делает опрос пиццы года?
М9. HTML — представление
Показывает пиццу клиенту, а так же принимает фидбэк (деньги, отзывы) и передает их администратору (JS).
М10. CSS — стилизация представления
Делает нужные отступы между двумя кусочками сыра.
Заметьте, администратор на телефоне не говорит как правильно укладывать сыр, а пицца не содержит чьего то разговора по телефону. Любая попытка манипулирования стилями при помощи js, или манипулирование js при помощи html — это изначально надстройка, это изначально плохо. Классы и обработка событий придумали не просто так.
Вы можете проставить класс: пепперони, салями, но не в вашей компетенции решать, как лежать сыру пепперони.
Вы можете проставить bind: если тебя пнули, не заплатили, скажи администратору. Но никак не стоит пихать администратора в пиццу. Он один, а пицц много! Если у вас пицц столько же сколько операторов, то М1.
И так, за что отвечают js, css, html — мы разобрались.
Теперь можно задавать целые ветки вопросов: как правильно готовить пиццу, как быстрее и удобнее доставить ее и как разговаривать в клиентов по телефону.
Мне хочется как то определить модное нынче слово "Компонент". По факту даже обычная кнопка это уже «Компонент», но я переопределю это на очевидных примерах. Кнопка это кнопка, а компонент:
1. Превью поста
2. Комментарий
3. Превью файла
4. Голосовалка на хабре
5. Блок «вакансии»
6. Html текст поста, рецензии, вебинара
итд
М11. Компонент везде должен выглядеть одинаково.
Куда бы вы не поместили превью поста, на какой странице бы вы его не открыли — он должен выглядеть одинаково. Правило трёх цветов. Все должно быть узнаваемо для пользователя
Модификации — вынужденные изменения, при необходимости. Делаются при помощи css.
Либо это другой компонент
(Например превью поста в правой колонке могут отличатся от превью поста внизу страницы).
М12. Компонент состоит из [html], [js], [css].
Каждая из частей опциональна.
М13. Вне зависимости от количества экземпляров одного и того же компонента, его стили должны быть прописаны только один раз
Например, превью поста справа, превью поста снизу, превью поста в уведомлении, а стили прописаны только один раз.
М14. В js компонента должны быть прописана только база
Например, обработчики событий при клике на кнопки, данные, необходимые для отображения. Все остальное должно быть вынесено вне.
М15. Компонент может состоять из компонентов
Например, список постов.
М16. Стили выноситься в отдельный файл
Эти файлы закешируются, к тому же не будет соблазна писать их инлайново, а значит дублировать.
М17. Стили компонента должны привязываться через классы родителей и только
Страница любого сайта, это как множество коробок разного размера, которые подобно матрешке вложены друг в друга.
Коробка — это компонент.
У вас есть коробка с коробками и элементами. Вам никогда не надо думать как описывать внутренности вложенной коробки. Описываете только эту.
Тут понапридумывали кучу велосипедов, но господа, никаких проблем с наименованиями не будет, как только для себя определите набор компонентов. Если вы откроете вконтакте и посчитаете там количество компонентов, ну штук 30 вы насчитаете. (В facebook не считайте, там только боль).
Не можете придумать 30 имен классов? И правильно, нечего придумывать:
М18. Ваш код будут читать другие люди.
А значит естественное название — лучшее название
Например
1. posts-list
2. comments-list
3. news-list
4. post-preview
5. comment-preview
6. news-preview
7. post-detail
8. comment-detail
9. news-detail
Невероятно сложно, да? А главное непонятно и поддерживать сложно
А про «читать другие люди» тоже отпишусь:
М19. Html, js, css должны храниться отдельно!
Если вам надо соединить их вместе, придумайте другое решение, чем писать их в одном файле. Реакт — самое отвратительное по читабельности, что я видел!
Страницу на «Коробки» поделили, как хранить файлы — обговорили. Что еще?
М20. Частных случаев почти не бывает
А если и бывает, то завтра придут ваши менеджеры на работе и скажут, что «надо модифицировать реализацию по просьбе заказчика». Решайте задачи максимально в общем виде.
Например, на своей работе, мы, вне зависимости от проекта, сразу отделяем некоторые задачи: календари, формы ввода, всплывающие окна, меню разной начинки, просмотр файлов и другие виджеты, взаимодействующие с пользователем. Так сказать «персонажи-функции»
М21. Написание стилей требует своей декомпозиции
Мир не просто так дал нам чудные LESS, SASS.
В вашем проекте есть фиксированный набор шрифтов, цветом, теней, почти все серьезные проекты имеют цветовые схемы, по этому при написании стилей все это параметризуется. И тут важно следующее
М22. Если вы захотите изменить цвет шрифта (итд), то вы должны внести правку только в одном месте
В заключении хотел бы отметить одну важную проблему.
М23. Правильная формулировка проблемы приводит к правильному решению
Возможно тогда бы не было css-in-js, facebook и то, чего нельзя называть.
Всем хорошего дня!
Автор: amiKonst
