что делать после верстки сайта
Четыре этапа разработки сайта, или 4 круга ада?
Публикация составлена совместно с командой Годунова.
Разработка проекта не начинается с полётом вашей мысли, разработке предшествуют, как минимум выбор исполнителя и прохождение по воронке продаж, но опустим вопросы внешней коммуникации с клиентом, за исключением брифинга, так как от него строятся все последующие этапы.
Заказчики и исполнители попадаются с разным пониманием этого термина, от заметок в телефоне, до трехсот страниц с юридическими терминами, и дефинициями, скажу, что второй вариант больше похож на описание технического задания. В этой статье подробнее про это все рассказывали, тут разобрано почему разработка технического задания подходит не всем. В статье представлена альтернатива в виде технической документации. На самом деле большинство на интуитивном уровне не составляют огромные ТЗ, а лишь описывают проектную документацию, по привычке называя это техническим заданием.
Функциональный прототип
Прорабатывать механики, логику, структуру сайта, и навигацию, стоит именно на этом этапе. Проект буквально расположен на бумаге, исправление неточностей не повлечет за собой таких издержек, как если бы они обнаружились на одном из последующих этапов. Чем дальше по конвейеру пробралась ошибка, тем больший объем работы придется проделать и заказчику и исполнителю, чтобы еë исправить.
Подбор референсов
После того как определен ассоциативным ряд, который должен возникать у пользователя, при использовании вашего продукта, можно подбирать визуальные решения которые будет подкреплять эмоции визуально. По большей части этап для дизайнера, и обратная связь от клиента нужна только для того, чтобы ваши представления о прекрасном не расходились, и дизайнер с наименьшего количества попыток попал своим дизайном вам в сердце.
В зависимости от масштаба и сложности проекта, к стандартной триаде технологий HTML&CSS&JS могут присоединяться различные надстройки в виде сборщиков проектов, препроцессоров, в особых случаях, например в веб-приложениях, обычного JS становится недостаточно и подключаются различные фреймворки например Vue или React, но статья не о технологиях.
Пару слов про технологии. Бэкэнд значительно превосходит фронтенд по количеству возможных решений, неправильный выбор либо создаст серьëзнве неудобства после ввода проекта в эксплуатацию, либо вовсе вынудит переделывать проект, поэтому выбор технологий должен быть обусловлен чем то более существенным, чем привычкой исполнителя работать с определенным стеком технологий.
При создании сайта, что нужно делать после того как он уже свёрстан на html и css?
Если Ваш сайт уже сделан на html и css, то WordPress или Joomla Вам не нужны, так как эти конструкторы нужны тем, кто не знает html.
Готовые файлы новых страниц своего сайта копируются с диска Вашего компьютера на хостинг при помощи любой программы FTP-клиент, например через бесплатную программу FileZilla Client.
4. Где логически располагаются сайты или что такое домены. У сайтов есть адреса в Интернете, это доменные имена. За регистрацию и ежегодное продление настоящего домена надо платить деньги регистратору доменов. Но на бесплатных хостингах Вам могут дать попользоваться бесплатным доменным именем третьего уровня. Владельцем домена считается только тот, чьё имя вписано в реестр домена второго уровня. Поэтому, в принципе, Вам могут дать бесплатно попользоваться и даже доменом второго уровня. Но это только на «птичьих правах».
Здесь САМЫЕ НИЗКИЕ ЦЕНЫ НА ДОМЕНЫ. Чтобы привязать свой домен к своему сайту, надо в панели управления доменом изменить у домена адреса DNS-серверов на те, которые Вам сообщат на хостинге.
Там если вы решили делать сайт на WordPress или Joomla, тогда нужно было сразу на нем делать, а вы зачем-то верстали его на чистом html и css.
Теперь нужно установить WordPress или Joomla на denwer и делать заново сайт. Естественно наработки можно взять с созданных вами html и css
Вам в любом случае понадобится для сайта доменное имя и хостинг.
Зарегистрируйте доменное имя, оплатите хостинг, залейте на хостинг всё что сверстали, и любуйтесь результатом!
Верстка сайта: инструкция для начинающих
Что такое вёрстка сайта
Вёрстка – это структура всех элементов на странице документа, сайта или другого информационного носителя. Такими элементами могут быть изображения, заголовки, подзаголовки, таблицы, инфографика и сам текст.
Изначально понятие вёрстки было применимо к издательской деятельности. Книги, газеты, журналы содержат структурированную информацию. В них есть чёткая сетка, блоки, в которых текст и графические материалы упорядочены таким образом, чтобы максимально облегчить читателю процесс потребления информации и заинтересовать его.
Сейчас актуальность вёрстки для издательств сохраняется, но к ним также примкнула и сфера веб-дизайна.
В разработке сайтов вёрсткой называется перевод дизайн-макетов в интерактивный, читаемый браузерами вид. То есть, верстальщик пишет код, который формирует из предоставленного графического шаблона «живую» веб-страницу, с элементами которой может работать пользователь.
В контексте создания сайтов есть два вида разработки:
Вёрстка относится к front-end. Она не отвечает за базовые возможности сайта, например, за регистрацию пользователей, товарную корзину или прочие операции, связанные с вычислениями, внешними и внутренними запросами, хранением и загрузкой данных.
Вёрстка правильно располагает все элементы на странице и делает так, чтобы с ними было удобно работать. Поэтому вёрстка сайта – это ответственная задача, требующая внимательности, терпения и постоянного тестирования.
Вёрстку веб-страниц невозможно представить без HTML. Если говорить простыми словами, то HTML — это единый стандарт отображения всех элементов веб-страницы. Это язык разметки, с помощью которого браузеры показывают нам порядок, размер, формы и шрифт текста. С его тегами знакомы все, кто занимался созданием сайтов, например:
Дизайн vs. Верстка?
На Хабрахабре уже не раз поднимался вопрос о том, что популярные на сегодняшний день жизненные циклы разработки веб-интерфейсов, прямо говоря, устарели. Последний раз его обсуждали в публикации «Дизайн в браузере», но так и не пришли к единому мнению.
Настало время наконец-то найти ответы на два главных вопроса: “Кто виноват?” и “Что делать?” в вечной борьбе дизайна и верстки…
Типовой жизненный цикл разработки веб-интерфейсов
Начать статью стоит с рассмотрения вопроса о том, как собственно происходит разработка веб-интерфейсов, кто в ней участвует, что конкретно делает и за что отвечает. Существуют десятки методологий, по которым строится жизненный цикл разработки веб-интерфейсов, но их всех объединяют базовые этапы:
Этап первый: Создание формальных требований на разрабатываемый интерфейс. Конечный результат этого этапа — бриф или техническое задание, где описано, что должно быть на макете, и как это будет реализовано. Занимаются этим люди с проектными ролями: бизнес-аналитик, технический писатель;
Этап второй: Разработка графического дизайн-макета по брифу или ТЗ. Данную работу выполняет дизайнер (веб-дизайнер, дизайнер GUI);
Этап третий: Верстка интерфейса (создание html\css\JS кода) по графическому дизайн-макету. Над версткой работает верстальщик (фронтенд разработчик, веб-разработчик).
Ограничиться базовыми этапами и получить высококлассный результат можно, пожалуй, только в “сферических условиях в вакууме”. На практике на каждом этапе возникает ряд проблем, решать которые приходится, вводя подэтапы и усложняя жизненный цикл разработки интерфейса.
Подробнее о возникающих проблемах и способах их решения поговорим ниже, начав с вопроса объективности оценки качества дизайн-макетов.
Проблема формальной оценки дизайна
Под разработкой дизайна веб-интерфейсов подразумевают работу по проектированию взаимодействия и оформлению внешнего вида веб-страниц. Внешний вид удобно передать в графическом дизайн-макете. Т.е. работа над дизайном сводится к созданию макета.
Оценка макета, по большому счету, субъективна. Часто строится на таких эпитетах, как красиво, нравится, приятный, аккуратный, и их вариантами с приставкой “не”… Качество макета оценивается по личным предпочтениям. Встает вопрос: а можно ли вообще формально оценить макет по субъективным критериям? Можно. И самый действенный способ — тестирование на фокус группе: набирается группа людей из целевой аудитории, для которой разрабатывается макет, проводится его демонстрация, после чего участники исследования заполняют анкеты-опросники, выставляя оценки исходя из своего личного мнения по этим субъективным параметрам. Среднестатистическое значение — адекватная оценка качества макета.
Часто ли на практике происходит такое тестирование на фокус группе? К сожалению, очень редко. Обычно всё сводится к согласованию личного мнения дизайнера и заказчика. При этом, по опыту, как исполнитель не всегда может адекватно оценивать свою работу, так и заказчик имеет бесполезное или даже вредящее качеству мнение. В итоге страдает конечный пользователь, ради которого, казалось бы, и делается макет.
Другой подход к формальной оценке макета основан на принципах взаимодействия с пользователями, которые иногда называют “Принципами Стива Джобса”:
Разработчики не считаются с мнением пользователей, сами определяя то, что нужно пользователю, т.к. разработчики — это эксперты и профессионалы, видящие ситуацию в целом и адекватно, а конечные пользователи в большинстве случаев сами не знают, чего хотят, и способны лишь наслаждаться результатом, который удовлетворяет их потребности, о которых они ранее и не подозревали.
По этим принципам в начале эпохи домашних компьютеров создавались решения от Apple, превратившие в произведение дизайнерского искусства эти самые ПК, в противовес “квадратно-практичному” внешнему виду продуктов конкурентов. Потребители сами не догадывались, что им понравится тот факт, что такая утилитарная вещь, как компьютер, может быть стильным дизайнерским решением. Но увидев реализацию, созданную дизайнерами, не считавшимися с мнением потребителя, все же положительно оценили её. Впрочем, это другая история, вернемся к разработке внешнего вида веб-страниц…
Да, многие дизайнерские студии работают над оценкой макетов по схожим принципам, без всяких фокус групп из представителей ЦА, самостоятельно определяя, каким должен быть макет, и получая в итоге очень удачный и качественный результат. Происходит всё то же самое, что и с фокус группой, только здесь собирается экспертная группа, состоящая из нескольких опытных дизайнеров, работающих в той же области, им также презентуется макет, и происходит его оценка.
Но, опять же, как часто на практике собираются экспертные группы, состоящие еще хоть из кого-нибудь, кроме исполнителя-дизайнера и заказчика? Кажется, мы об этом уже говорили…
Формальная оценка качества дизайн-макета возможна, но на деле редко осуществима. Любая индивидуальная оценка — субъективна, и это помимо прочих проблем разработки веб-интерфейсов…
Несоответствие ощущений от графического макета и сверстанной веб-страницы
Проблема, озвученная в подзаголовке, хорошо известна в среде веб-дизайнеров:
Как бы качественно и детально ни был отрисован макет, он остается графическим изображением, иногда его ещё называют “мертвым” макетом. Даже если вы разрабатываете дизайн веб-страницы, где нет динамических элементов (раскрывающихся меню, меняющихся по клику теней и т.д.), все равно ваш макет по ощущениям отличается от конечной, сверстанной страницы (даже на статике можно выделить текст, проскроллить и прочее).
Касается эта проблема и удобства использования. Частично юзабилити-экспертизу можно провести и по графическому макету (оценив расположение и компоновку элементов и т.д.), но полноценно понять, насколько удобным оказался интерфейс, выявить все подводные камни в работе с ним, можно только по конечной, готовой веб-странице.
Сюда же идет и ещё одна беда как дизайнеров, так и верстальщиков — отсутствие контента. Порой в брифе написано: “здесь на странице текст, а здесь — картинка”. А что это за текст, какого он размера, сколько абзацев и заголовков в нём; что там за картинка, в какой она цветовой гамме, какие у нее пропорции — не указано. Тогда приходится в дизайн-макете использовать “рыбу” (заглушки) — сторонние тексты, картинки. Иногда их же приходится применять и при верстке. А после, когда на странице размещается уже конечный, рабочий контент, ужасаться конечному результату,
Выходит, даже если изначально дизайн-макет оценивался положительно, оценка конечного результата может сильно поменяться в худшую сторону.
Как можно было бы избежать всех этих проблем при разработке веб-интерфейсов
Что мы имеем в итоге? Озлобленных дизайнеров, рисующих N’ую версию макета и правомерно заявляющих: “нужно более формально задавать требования к макету”. Не менее раздраженных верстальщиков, переверстывающих страницу в M’ый раз. Дополняют эту картину растянувшиеся сроки, проваленные дедлайны, превышенные бюджеты и извечные вопросы “Кто виноват?” и “Что делать?”
Всего этого можно было бы избежать, если изменить типовую модель жизненного цикла разработки веб-интерфейсов. После небольшой корректировки, она выглядела бы так:
Этап первый: Подготовка контента;
Этап второй: Создание краткого брифа с описанием функциональности и формальных требований к разрабатываемому интерфейсу;
Этап третий: Быстрая разработка интерфейса в тех условиях, где он будет использоваться (прямо в браузере), сразу верстая его как готовую веб-страницу, с непрерывной экспертной и юзабилити оценкой.
Все проблемы исчезают сами по себе, конечный результат всегда на высоком уровне, в дополнение — сроки и расходы на разработку сокращаются в несколько раз, по сравнению с существующими типовыми жизненными циклами разработки веб-интерфейсов. Спрашивается, почему все до сих пор не пользуются такой удачной схемой? На самом деле, как раз сейчас такой подход набирает обороты.
Там же, в комментариях были озвучены и другие примеры, говорящие за актуальность описанного подхода — это появившиеся в недавнем времени специализированные продукты. Во-первых, это решения для быстрого создания прототипов веб-страниц, такие как: www.axure.com, http://froont.com. Во-вторых, это программы и сервисы нового поколения, где при визуальной разработке макета, сразу генерится готовая верстка (и в отличие от похожих продуктов “старого поколения”, эти решения генерят чистый и лаконичный код, как будто его писал высококлассный верстальщик): http://macaw.co, https://webflow.com.
Продукты для создания прототипов хороши тем, что можно быстро получить визуальный результат, но о лаконичной и чистой верстке, а тем более о полноценных интерфейсах, созданных в них, речи не идет. Решения, которые генерируют качественный код, нельзя назвать простыми, и быстро работать в них не получится. Порой время работы с ними, напротив, соизмеримо или даже дольше, нежели в случае, когда сперва нужно отрисовать графический макет, а затем “вручную” его сверстать. При этом ни в тех, ни в других нет возможности работать над макетом в тех условиях, в которых он будет использоваться (т.е. прямо в браузере, с отсутствующими рабочими элементами редактора). Да и функция автосохранения и хостинга проектов, дающая непрерывный доступ к промежуточному результату третьим лицам (для оценки качества, юзабилити-экспертизы и т.д.), имеется далеко не у всех…
Когда появится решение, лишенное всех этих недостатков и способное полноценно реализовать предложенный жизненный цикл разработки веб-интерфейсов, остается лишь вопросом времени. Все тенденции ведут именно к такому продукту.
Если вас заинтересовала проблематика, описанная в статье, и её решение, в качестве бонуса предлагаем посмотреть вот это короткое видео — http://www.youtube.com/watch?v=nIOVU9_KRKA
Кирилл,
руководитель проекта Mockup editor SletchBuilder
В соавторстве с нашим дизайнером Сергеем Sevenvampire и веб-разработчиком Антоном skrutty.
Семь простых советов о том, как не надо верстать
Эта статья является продолжением моего «крестового похода» против ветряных мельниц убогих современных тенденций в разметке и оформлении веб-приложений (статья1, статья2). И, поверьте — солидная ее часть — это толерантная, такая, чтобы никоим образом не нарушить NDA, переработка реального доноса код-ревью кода важного боевого проекта для руководства одной из команд в которых мне приходилось участвовать. До этого момента я породил уже три достаточно злых, токсичных длиннопоста для сообщества, и, о чудо — ни один из них не умудрился скатился в минус (но последний был близок). И на этот раз — я готов! Ибо этот пост именно о тех технологиях и подходах к верстке, которые мне[, конечно же, на основе коммерческого опыта] кажутся весьма неудачными и неэффективными, неадекватными в очень многих ситуациях. Конечно, существуют команды, проекты, требования когда каждый из этих подходов может окажется вполне приемлемым и уместным. Но на деле, чаще всего, имхо, оказывается, что поборники данных методов — безальтернативно «подсаживаются на любимую иглу» и упорно не хотят знать и уметь, использовать ничего другого. Мне вообще кажется, что мир вокруг нас сейчас это — утопия, практически целиком, максимально упрощенная тотальным засильем пролоббированного рептилоидами, мировой закулисой корпорациями тоталитарного глобального мейнстрима, и это одинаково касается всех сфер жизни, вот тут можно почитать мою философскую статью на тему применительно как раз к интерфейсам Куда подевались социальные сети? Пропаганда и реклама вместо общения. И даже наш любимый журнал о технической культуре, по сути, превратился в рекламную помойку, по большей части, унылое отражение глобального общественного тренда. Но, как известно — «главное попытаться», поэтому — поехали!
Ошибки в работе с пространством
Неоправданное и, при этом, неявное использование flexbox
Когда наконец закрыл висевший пару месяцев баг
Совет 1. Особенно передавая статичный макет для pixel-perfect — опирайтесь на обычный статичный поток, используйте контейнеры, обертки которым можно выставлять высоту или абсолютное позиционирование относительно relative-родителя. Изучите, хотя бы бегло, старперские простые классические приемы, используйте Grid-раскладку для собственно сеток, а Flexbox-модуль — только там где это действительно необходимо и уместно. Чаще всего: для «мелкого», локального позиционирования внутри небольших конечных блоков, виджетов.
«Бесхребетная» разметка
Что бывает когда все написано на flexbox и не формирует в статичном потоке четкие контейнеры и обертки с фиксированной высотой? Все разваливается и едет — в самых неожиданных или вполне ожидаемых местах. Элементы ведут себя менее предсказуемо, очевидно, по определению — более гибко, резиново, и это часто создает проблемы с тем, чтобы передать макет точно, например когда мы пытаемся переиспользовать и модифицировать «уже готовые» шаблоны-паттерны на похожих видах — постоянный сплошь и рядом встречающийся кейс в веб-дизайне. Очень часто эта «резиновая верстка» статичных макетов еще и «висит на контенте». Немного изменились данные, текстовый контент приходящий с бека, строк стало больше — вообще вся страница поплыла. В хорошей надежной продуманной верстке баг если и появляется, то только один раз и дальше он уже надежно фиксится. Но мне приходилось видеть, как одни и те же проблемы «возвращались по кругу», возникали много раз. Потому что изначально все было сделано настолько безобразно-дурно, что геройски переписать надежно — уже очевидно слишком дорого, а править с помощью кряков и хуков, на самом деле — также дорого, но еще и крайне неприятно, отвратительно, мерзко. Но приходилось править, конечно, что не переписал геройски по всему репо, так как «бизнес есть бизнес, детка».
Котик смотрит на твою верстку на React с CSS-in-JS
Я заметил что пишущие на React c CSS-modules молодые фронтенд-программисты часто как будто «экономят divы». И понятно почему: «якобы излишнее обертывание элементов в блоки в стиле БЭМ» это уже не модно и они просто так уже не мыслят. У нас сейчас наконец-то все просто и ясно, никакого творчества-отсебятины: блок это компонент, внутри — элементы строго как в дизайне, ничего лишнего, плюс надежный модуль стилей для каждого! Даже если эта надежность совершенно излишняя и запутанная, а нам, наоборот, нужна легкая и быстрая модификация, переиспользование. О том как бывает тяжело изменять такую надежность и как на самом деле эта святая простота выглядит в коде — я расскажу немного ниже.
Совет 2. Не «экономте
Магические кряки и хуки вместо просто хорошей верстки
Какой-нибудь очередной «манипулирующий с DOM» хук, например, опирающийся на «магические айдишники» (а ref-ы уже не получится использовать, так как у нас все в разных несвязанных компонентах) — всегда придет на помощь, даже если вместо этого нужно было вовремя осознать и написать один «лишний»
и простые стилевые правила к нему. Нет, мы не ищем простых путей, предпочитаем писать хуки на единственной технологии которую хорошо знаем и потом подбирать возвращающиеся баги когда эти кряки отваливаются. Не очевидное но важное заблуждение пишущих исключительно в описываемом стиле разработчиков в том, что сложный современный дизайн вообще возможно качественно и быстро «разметить» полностью избегая выделять отдельный слой глобальной стилевой абстракции и пользуясь одной только компетентностью, только ей ограничивая переиспользуемость. Может быть с помощью CSS-in-JS действительно удобно верстать некий строгий интерфейс с виджетами большой командой, в котором «рюшечки не важны». Но не, например, набор «бохатых-шикардосных» лендингов быстро с красивым размашистым дизайном и повторяющимися, но разнообразно модифицируемыми паттернами на них. Дальше я расскажу о том почему использование CSS-in-JS на подобных проектах это большая ошибка и мешает делать быструю качественную верстку.
Совет 3. Очень банальный, хорошо известен: делайте с помощью верстки все что можно сделать версткой. Делать плохую верстку для того чтобы потом фиксить ее хуками — это ненадежно, срывает сроки и общепризнанно плохой стиль.
Нипофиксиль, ниуспель
Неадекватные сложности дизайнов, целям и задачам, срокам и бюджету проектов технологии
В дизайне очень часто встречаются модификации, отклонения, исключения — дизайнеры все очень творческие, в клиенты иногда — еще более творческие, и, главное — требовательные. Давайте поглядим что нам нужно было сделать раньше для того чтобы модифицировать набор стилей на некотором элементе, скажем так: на HTML с глобальными стилями на любом препроцессоре, псевдокод:
А теперь возьмем некий модный проект на, конечно же — передовых технологиях от bigTech-гигантов занимающих 80-85% рынка вакансий, например React [c GraphQL] + Flow (TypeScript это для умников, энтерпрайза и игры в долгую, понятно) + да и такое бывает, честное слово: SCSS + «стандартной технологии для защиты стилей» CSS Modules + Styled Component тоже прикручены.)))
Забегая вперед: то, что раньше действительно, без преувеличений — делалось за две минуты, сейчас иногда занимает полчаса и чревато сложноуловимыми неочевидными ошибками. Вот этот наш простой самый распространенный будничный прием при переиспользовании разметки — нужно из «конечной вьюхи» прокинуть класс-модификацию для специфической стилизации элемента на данном специфическом виде. Теперь нам нужно проходить через всю цепочку компонентов чтобы передать класс, при этом, слов нет, везде проверяя что это string с Flow и нигде не ошибиться. Давайте посмотрим как выглядит наш код, переиспользуемый компонент-шаблон в библиотеке @src/components/Template/Template.js, очень упрощенно, в реальности все намного сложнее:
Плюс индекс, стили и еще целая папка-матрешка с глубокой вложенностью вот этого всего, в дочерних компонентах и так далее. Причем вот тут — на «общем верхнем виде» — все будет действительно очень плохо, безобразно адово — количество объявлений типов в PropTypes компонента будет стремиться к стопитцот — и чем больше модифицируется ваша вьюха на конечных видах — тем стремительнее.
Ну и теперь мы наконец можем слепить конечный вид для роутера — который будет все это использовать в @views/View/Reals/RealView.js:
Ну, и, конечно — специфические стили для этого конечного вида.
Что, правда? Мы же просто хотим передать один несчастный модификатор? Но видим запутанную сложную структуру, множество файлов, и нигде в этом лабиринте нам надо не забыть передать стиль, еще и проверяя что это строка? Это не только жутко выглядит, отнимает лишнее время, крайне утомляет и раздражает, так еще и просто совершенно бессмысленно по сути. Как будто мы сами «вставляем себе палки в колеса». Справедливости ради, в CSS Modules присутствуют минимальные возможности переиспользования кода, некой низовой абстракции, или можно, например, выделять глобальные стили. Но первое, по моим наблюдениям, обычно не используется фэнами данного подхода, как и, например, препроцессор, если он прикручен, но, в результате, по сути «задавлен Модулями». У нас есть «исходные классы переиспользуемых компонентов-прототипов» и при необходимости они с трудом перекрываются «переданными по цепочке» классами от конечных вьюх. Код копируется и раздувается, содержит одно и тоже. В глазах рябит от одинаковых селекторов на разных уровнях. Поиск затруднен. Для того чтобы создать и передать простой класс-модификатор мы вынуждены вносить изменения не в два (конечная разметка и стили), а, чаще всего, в целые цепочки файлов — это очевидно увеличивает риск конфликтов при мерджах. А я то ожидал что «все наконец будет в одном месте»? Как бы не так! Ты мечешься по огромной сложной запутанной системе компонент и стилей для них, пытаясь сделать то, что бы мог надежно и понятно для последователей сделать за пару минут с нормальным глобальным препроцессором или даже просто на CSS. Я не заметил никакой «защиты» [которая часто вообще просто не нужна] — те же самые конфликты специфичности по-прежнему возможны. Ну, то есть, мы просто теперь очень дико, странно и трудно делаем то, что раньше делалось очень просто. Какие такие «глобальные конфликты» возможны если писать на БЭМ обычную надежную верстку без прокидывания классов и проверки их типа и прочих танцев с бубнами? Зачем мне такая «полезная» технология, что она дает в случае вот нескольких похожих друг-на-друга, но, при этом, всегда немного разных «бохато-шикардосных» лендосов? Мне показалось, только очень сильно и очевидно мешает? Мне кажется это «заговором» против абстракции в стилях и «обычной верстки» — которая способна формировать дополнительный к компонентной структуре фреймворка, легко стилизуемый классами CSS слой. Клиент ждет от нас хороший дизайн, а мы сосредотачиваемся на сомнительном оверинжиниринге, который, вероятно, этому только мешает, пишем функционально-декларативный Реакт [с GraphQL] и самыми модными технологиями для стилизации, типизацией — прямо как на каком-нибудь курсе «синьор за 3 месяца» или хакатоне. Только когда все это сталкивается с реальностью и дизайном боевого проекта — становится даже жарче чем на хакатоне.)
Совет 4. Никогда не использовать React c CSS-Modules на проектах где нужна быстрая, но четкая верстка и переиспользование. Эта технология не дает ничего действительно нужного и полезного, но очень сильно затрудняет и ограничивает самые простые привычные вещи: блокирует препроцессор и эффективную модификацию оформления.
Ах, да! У нас же еще есть Styled Component, и теперь у нас уже «почти полный набор известных технологий для стилизации» — как «на выставке». Также как и Модули, SC ограничивают возможности стилизации и переиспользования верстки [исключительно компонентностью]. Да мы можем удобно, понятно перекрывать исходные стили модификациями по пропсу в самом компоненте. Но также неминуемо возникает проблема с доставкой этих модифицирующих пропсов и опять выглядит некруто. А если компоненты не связаны? Маппить со стора, через контекст? Совсем чудовищно, когда можно «просто нормально верстать». Кроме того, при использовании обоих технологий одновременно: хеши SC встают слева от хешей Модулей, перекрывая их, что еще увеличивает сложность, беспорядок, вероятность ошибок.
Совет 5. Никогда не используйте «все технологии сразу», даже если ваш коллега Вася привык и очень хочет, не знает препроцессор и так далее. Используйте только что-то одно, и именно то, что будет выгодно в контексте требований и сроков конкретного проекта.
Говоря о методологиях для разметки сразу вызывающих оторопь в контексте проектов со сложными нетривиальными дизайнами или же крайне сжатыми сроками, нельзя не вспомнить действительно древний подход не ассоциирующийся с мировым злом рептилоидами экосистемой самого популярного (почему-то здесь ассоциация с «продукцией» пивца Моргенштерна) ныне фронтенд-фреймворка Реакт. Это «утилитарный метод» получивший ныне свою вторую жизнь в качестве мейнстримно CSS-in-JS-ной реализации Tailwind с ее оголтелым слоганом-оксюмороном: «“Best practices” don’t actually work». Если вы видите на шаблонах нечто подобное:
Значит это оно! Я встречал проекты в которых авторы еще и «ловко», «умно» генерили утилиты с помощью хэшей/мапов и миксинов препроцессора. В этом случае — у вас даже нет шанса просто найти класс по поиску среди обычного списка в стопитцот утилит (зато вхождений на разметке — абсолютно точно будет стопитцот). Но даже продвинутый Tailwind «который используют bigTech-акулы-гиганты», с его обещанными плюшками в виде небольшого размера бандла или даже передачей «атомарного тренда» в дизайне — весьма сомнительно что способен предоставить настоящую гибкость и эффективность в условиях нереальных сроков или меняющихся/недорисованных макетов — а оно очень часто именно так и бывает в жизни. В любом случае, если вам нравиться устраивать такой нечитаемый кромешный ад на разметке вместо идеального БЭМа — пожалуйста. Только не зовите меня когда макеты изменятся, «наконец приедут гаджеты» и надо будет «все переверстать».)
Совет 6. Не используйте утилитарный подход или Tailwind в случае горящих сроков и меняющихся или не до конца известных требований.
Дурная компонентность
Чаще всего, я вижу, что в уже распиленных проектах структура на верхнем уровне в @src/components — структура компонент крайне куцая и скудная (некоторые адепты Риакт еще, кажется, любили выделять «контейнеры» — но, имхо, им самим часто не до конца понятно — по какому именно признаку)) ). А на видах, наоборот — глубокая и чрезмерная, еще и с огромным количеством стилей. Изменения иногда создают проблемы, приводят к потере кода при мерджах, а наименование при этом как-будто специально стремиться еще больше запутать и сбить с толку. Я то вообще радикал, и считаю что виды вообще не должны содержать стилей, а компоненты в библиотеке — не должны обвязываться со стором. И, на самом деле, для того чтобы осознать почему это так, чем крайне выгодно — нужно просто вдумчиво-аккуратно написать несколько больших проектов.
Мне всегда казалось что самый надежный и удобный для быстрого поиска подход с React — когда мы стремимся дать компоненту уникальное для проекта имя, файл называется также, и кроме того — экспортиться и используется он точно по этому самому маркеру (конечно, в реальности бывают исключения из правила). Очень удобно искать и все сильно упрощает. Или, может быть, кто-то мыслит и читает репо только в маштабах одной актуальной таски, но не всего проекта? Работая со Vue/Nuxt, например, удобно ввести соглашение, что мы называем и используем в разметке кастомные компоненты только в PascalCase-стиле. А сторонние — в kebab-case.
На самом деле, в реальности — иногда ваши коллеги даже не пишут собственно компонент работая с компонентным фреймворком, и кажется, даже не совсем понимают что это такое, для чего именно нужно. Они просто копируют куски кода или целые файлы по видам, с проекта на проект. Недавно у меня был опыт на невозможно-переборно-авральном, но крайне важном, значимом проекте с коллегой-фуллстеком на 10 лет старше меня (а мне уже 40). Он начал с верстки двух похожих страниц-форм, содержавших множество полей ввода. Сверстал одну страницу «обычной версткой» — без использования компонент, и, при этом — игнорируя требования макетов/дизайн-системы относительно внешнего вида и поведения плейсхолдеров или сообщений валидации. Потом скопировал все это на другой роут, переименовал классы и немного видоизменил под макеты. Готово — «пока так сойдет». Когда я вежливо поинтересовался «а как называется этот потрясающий стиль программирования на фронтенде?» коллега принялся авторитетно поучать про «инкапсуляцию», и то, что «компонент это модуль»)). Через месяца полтора команда справилась с основным объемом и руководство с дизайнерами подняли вопрос что «формы выглядят не по макету»! Если бы изначально было потрачено на пару часов больше и аккуратно использовались компоненты — достаточно бы было внести изменения действительно — в одном месте — чтобы все легко поправить. Вот тебе и инкапсуляция!
Помню, один из моих бывших боссов рассказывал про знакомого, который прошел жесточайший отбор в Google на должность некоего важного директора в Долине. Через какое-то время он посетил родину, и кореша за пивком поинтересовались закономерным: «А что ты, твой отдел делает?». Персонаж открыл какой-то из множества сервисов и ответил: «Вот эту кнопку!». Вероятно, это была очень важная и сложная суперкнопка, безусловно. Но многим из нас не так повезло в жизни, и на текущих проектах приходится делать очень много разных кнопок-контролов и всего прочего, с самыми разными людьми, и в разных обстоятельствах, ситуациях.
Совет 7. Полезно стараться организовать как можно более плоскую и понятную, подробную структуру компонент на проекте. При этом удобно формировать некую вообще практически линейную максимально детализированную «библиотеку» переиспользуемых компонент, а на видах их использовать. В идеале виды вообще не должны содержать стилей, а компоненты в библиотеке — не должны обвязываться со стором.
Сегодня мы многое поняли
На самом деле, не рептилоиды Цукерберг мировая закулиса «написала четыре миллиона проектов» с отвратительной архитектурой, на сомнительных подходах-технологиях, с отвратительными кодом и версткой. Если в описанных выше подходах ты узнал свойственные тебе привычки и манеры, но при этом ты хочешь чувствовать себя разносторонним профессионалом на фронтенде, возможно — пора меняться, пробовать что-то новое/другое.