Перевод статьи Components and concerns c сайта adactio.com, опубликовано на css-live.ru с разрешения автора — Джереми Кита
Порой мы слишком увлекаемся ложными противопоставлениями в мире веб-дизайна и веб-разработки. Недавно я подметил одно, регулярно всплывающее в области дизайн-систем и компонентов.
Это насчет разделения ответственности. У веба долгая история разделения структуры, представления и поведения с помощью HTML, CSS и JavaScript. Оно служило нам верой и правдой. Если писать код в таком порядке, добиваясь, чтобы нечто работало (в какой-то мере), прежде чем добавлять следующий слой, результат будет надежным и устойчивым к сбоям.
Но в теперешнюю эру компонентов многие указывают, что есть смысл разделять вещи в соответствии с их функцией. Вот что пишет Дайана Маунтер в своей великолепной статье о дизайн-системах на Гитхабе:
Вместо того, чтобы разделять ответственность по языкам (как HTML, CSS и JavaScript), мы стремимся к модели разделения ответственности на уровне компонентов.
Это очень созвучно тезису, высказанному ранее в презентации Кристиано Растелли.
Разделение ответственности в соответствии с задачей каждого компонента более чем логично… но это не значит, что надо перестать разделять структуру, представление и поведение! Почему бы не делать и то, и другое?
В «традиционном» разделении ответственности в вебе (HTML/CSS/JavaScript) нет ничего, что ограничивает его только простыми страницами. Я бы сказал, что она как раз лучше всего работает, если применять ее на уровне чего-то мелкомасштабного.
В своей статье «Сначала библиотека паттернов: подход к управлению CSS» Рейчел советует начинать каждый компонент с хорошей разметки:
Вам всегда стоит начинать с хорошо структурированной разметки.
Это гарантирует, что ваш контент доступен на самом базовом уровне, но это еще и значит, что вы можете использовать преимущества нормального потока (т.е. самой базовой CSS-раскладки, блоков и строк текста — прим. перев.).
По сути это подход по правилу языка с наименьшими возможностями (чем более мощным языком обрабатываются данные, тем сложнее как-то использовать эти данные в дальнейшем, поэтому если задачу можно решить простым, чисто описательным языком, не надо выбирать сложный процедурный; иногда считается частным случаем принципа минимальных привилегий применительно к выбору языка — прим. перев.). В главе 6 книги «Устойчивый веб-дизайн» я наметил трехэтапный процесс, которым я руководствуюсь при разработке для веба:
- Определить основную функциональность
- Сделать эту функциональность доступной с помощью самой простой технологии, какой только можно
- Добавлять улучшения!
Та глава полна примеров, как применять эти шаги на уровне всего сайта или продукта, но не надо на этом останавливаться:
Этот трехэтапный процесс можно применять и в масштабе отдельных компонентов на странице. «В чем основная функциональность этого компонента? Как мне сделать эту функциональность доступной с помощью наипростейшей технологии? А как теперь я могу ее улучшить?»
У разделения ответственности при создании страниц и при создании компонентов есть еще одно общее преимущество. В случае страниц, вопрос «В чем тут основная функциональность?» поможет вам подобрать хороший URL. Применительно к компонентам этот же вопрос поможет придумать удачное имя… а это то, из чего складывается ядро хорошей дизайн-системы. В своей блестящей книге «Дизайн-системы» Алла рекомендует задавать вопрос «В чем цель?», чтобы добиться хорошего общего языка для всех, кто работает с компонентами.
Мой тезис таков:
- Разделять структуру, представление и поведение — это хорошо.
- Разделять интерфейс на компоненты — это хорошо.
Эти идеи не противоречат друг другу. Представлять их как некий взаимоисключающий выбор — всё равно, что говорить «раньше я ел итальянскую еду, но теперь я пью итальянское вино». Они лучше всего работают в комбинации друг с другом.
P.S. Это тоже может быть интересно:
