Технологии, лежащие в основе одностраничных программных приложений на основе браузера, развиваются молниеносно. Кажется, что каждый год выпускается новая библиотека внешнего интерфейса или новая версия библиотеки внешнего интерфейса со всем новым синтаксисом и методами для управления состоянием, хранения данных и сегментирования кода на более мелкие фрагменты.

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

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

Если он не сломан, не чините его. CSS не проблема. Это неспособность понять, как написать это хорошо.

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

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

У каждого есть свое мнение, но вот как я бы определил хорошую фронтенд-стратегию.

Начните с доступности спереди и в центре

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

Потратить необходимое время на захват события, вызвавшего отображение модального окна, захват и обработку фокуса внутри элементов, а также правильное разрешение после закрытия — это совершенно новый шарик воска. Разработчики не разбираются в этом, поэтому он исключен из реализации до тех пор, пока не будет достигнут определенный уровень стандартов WCAG. Модальные окна и настраиваемые выпадающие меню, как правило, выводят доступность из воды, но это не относится к простым вещам, таким как теги alt и title или семантический HTML. Что подводит меня к следующему пункту…

Пишите семантический, простой HTML

При написании HTML спросите себя, как лучше всего представить данные, которые поддерживает этот элемент? Является ли это списком определений заголовков и данных, которые они представляют? Это статья с боковой панелью связанного контента (в стороне)? Это упорядоченный список? Это что-то, на что пользователь действует и нажимает, чтобы выполнить функцию? Или перевести пользователя на другой маршрут?

Каждый из приведенных выше примеров имеет разметку для поддержки смысла содержимого.

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

Использование ‹div› для всего и размещение событий onClick для всего, от ‹span› до ‹p›, возможно, является наиболее вопиющим примером злоупотребления разметкой. Пожалуйста, не делайте этого, но если необходимо, используйте метки ARIA для описания контента.

Хорошим справочником по семантическому HTML, конечно же, является документация MDN:

Держите Sass простым, легким для понимания

Пишите поддерживаемые стили. Sass поможет вам написать чистый CSS. Это не фреймворк как таковой, а способ написания стилей перед легкой предварительной обработкой в ​​CSS. Из коробки он наполнен множеством потрясающих функций. Он делает много вещей.

МНОГО. ВЕЩЕЙ.

Слишком много, если вы спросите меня. Один чрезмерно амбициозный Javascript-инженер пытается доказать свои навыки CSS, и это может очень быстро стать очень сложным. В том же духе отказ от CSS в пользу фреймворка стиля, ориентированного на полезность, такого как Tailwind CSS, который меняет все, делая его более сложным, и в конечном итоге создает ненужную абстракцию от простоты, которую CSS и разделение задач призваны обеспечить.

Лучший CSS прост в использовании. Легко понять. Быстро поддерживать. Селекторы настолько специфичны, насколько это необходимо. Не переусердствуйте. CSS не нужно исправлять. Не злоупотребляйте этим, и вы должны быть в порядке.

Функции SASS, которые я часто использую:

Глобальные стили с помощью @import

У меня всегда есть глобальный файл CSS, который включает в себя различные вещи, необходимые на глобальном уровне. Обычно это включает сброс CSS, глобальные стили HTML, типографику, сетки и утилиты. Такие вещи, как кнопки и элементы формы, могут лучше подходить для стилей на уровне компонентов.

Переменные и миксины

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

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

Вложенные стили

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

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

Стили уровня компонента

Стили уровня компонента сопровождают HTML и JS для компонента. Он специфичен только для компонента, но по пути может использовать некоторые из этих глобальных переменных или примесей.

Напишите лучшие селекторы

Написание лучших селекторов улучшает чистоту HTML и упрощает CSS.

Я буду краток. Этот приведенный выше пример все время происходит в руках очень, очень старших инженеров. Таким образом, вы принимаете их код как хороший. Но это не так.

Мой инженер-наставник, Джейми Лазарус, однажды сказал мне: «Если вы когда-нибудь увидите что-то повторяющееся в коде, это хорошее место для его улучшения».

В то время он имел в виду JavaScript, но я думаю, что он хорошо подходит для выбора селекторов. Чаще всего я вижу что-то вроде ниже. Там, где CSS будет иметь класс .tile со стилями, .til-list также будет иметь стили.

Но это можно упростить, используя только селектор .tile-list и комбинатор прямого потомка. .tile-list › li {здесь идут мои стили плитки}.

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

Начните с малого и работайте над собой

Предположим, что к каждому дизайну, над которым вы работаете, применена некоторая адаптивность или отзывчивость, даже если дизайнер не проектировал его с первого раза. Если исследования не показывают, что продукт, который вы создаете, будет использоваться только при определенном разрешении или размере браузера, Product всегда предпочтет иметь адаптивное приложение, а не его отсутствие. Дизайнеры иногда, но не всегда, думают о том, как структурированный HTML, как на более крупном уровне сетки, так и на уровне более мелких компонентов, будет обрабатываться в разных разрешениях браузера. И как они могли?

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

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

Фронтенд-инженеры, ради всего святого, сначала напишите свой CSS и HTML из небольшого размера. Начните увеличивать ширину браузера, и когда дизайн выглядит дерьмово, это хорошее место для точки останова с использованием min-width.

Сначала напишите свой CSS от наименьшего размера и используйте min-width, и вы будете вознаграждены гораздо более чистым CSS. Намного проще в обслуживании.

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

Некоторые полезные ссылки и ресурсы