Методичность — важное качество, когда дело доходит до веб-разработки. За годы своей работы я понял, что программное обеспечение основано на шаблонах и согласованности. В этой статье я описываю свои шаблоны для разработки компонентов пользовательского интерфейса, которые полностью не зависят от фреймворка. При таком подходе я обнаружил, что код, который я пишу, удобен и прост в обслуживании.
Начните с разметки
На мой взгляд, HTML-разметка — лучшая отправная точка для разработки пользовательского интерфейса. Он устанавливает структуру компонента и обеспечивает основу для данных, которые он представляет.
Кроме того, это помогает мне как разработчику лучше понять суть данных и то, что следует учитывать. Какие события укажут, что пользователь хочет получить больше информации? Какие эвристические принципы действуют? Как и когда интерфейс должен быть преобразован, чтобы обеспечить лучший пользовательский интерфейс для контекста, в котором он существует. Многое из этого раскрывается, когда данные записаны в четкой иерархии. Процесс написания разметки помогает мне ответить на основные вопросы о семантической структуре данных. Это список элементов или, возможно, список категорий, каждая со своим собственным списком элементов?
Какими бы обыденными ни были ответы на эти вопросы, они помогут создать наиболее подходящий пользовательский интерфейс. С элегантной реализацией что-то столь скучное, как меню или слайд-шоу фотографий, может быть определенно приятным и интуитивно понятным для навигации.
Получите максимальное количество имен классов
После написания кучи ванильного HTML стилизация становится следующим уровнем усовершенствования. Первым шагом является применение классов CSS к разметке. Лично я следую соглашению об именах БЭМ, описанному Гарри Робертсом.
Этот подход оказался исключительным решением, поскольку он разъясняет, какие селекторы и правила стиля требуются. Это также лучше информирует, какие элементы требуют более или менее конкретных правил для достижения дизайна.
Это может быть очень сложной частью процесса, потому что вам нужно решить, какие части вашего пользовательского интерфейса являются общими для остальных компонентов вашего приложения. Идея в том, что вы не дублируете код и не изобретаете велосипед, когда дело доходит до правил css.
Размеры шрифта, цвета, отступы, поля и границы — все это общие атрибуты в любом приложении, и важно, чтобы эти правила были привязаны к одному или нескольким определениям. Делая это, вы спасаете себя от беспорядка правил, которые становится все труднее поддерживать по мере роста и развития проекта. Имейте в виду, что согласованность — очень важный аспект разработки хорошего веб-интерфейса.
Добавьте JS для интерпретации действий пользователя
Когда внешний вид пользовательского интерфейса готов, я могу сосредоточиться на том, как пользователь может взаимодействовать с моим компонентом. Если мобильный, что происходит, когда они нажимают или проводят по экрану? Как компонент реагирует на каждый клик и как он должен информировать систему о том, что действие произошло.
Компоненты пользовательского интерфейса должны иметь четко определенный интерфейс для взаимодействия в контексте, в котором они были размещены. Он должен предоставлять крючки, которые позволяют системе реагировать любым способом, который она решит. Роль компонента состоит в том, чтобы просто интерпретировать примитивное действие пользователя (щелчок, касание, наведение курсора, пролистывание) во что-то значимое для системы (отправить заказ, просмотреть фотографии, добавить в избранное).
Установив, чего ожидать от компонента, приложение может строиться на основе этого компонента с гарантией того, что оно обработало каждое действие пользователя надлежащим образом, не принимая во внимание специфику взаимодействия или отображения данных.
Вывод
Следуя порядку перехода от HTML к CSS и JS и понимая роль каждого слоя, я нашел способ писать код, который подходит для гибкого подхода к разработке, при котором требования постоянно меняются. Я меньше ворчу и чаще говорю «да» менеджерам по продукту. Вместо того, чтобы объяснять, почему что-то не работает, я применяю более систематический мыслительный процесс для удовлетворения их просьбы. В конце концов, это означает меньше головной боли для меня и других разработчиков, когда их просят улучшить наше программное обеспечение.
