Компоненты и разделение ответственности

Перевод статьи Components and concerns c сайта adactio.com, опубликовано на css-live.ru с разрешения автора — Джереми Кита

Порой мы слишком увлекаемся ложными противопоставлениями в мире веб-дизайна и веб-разработки. Недавно я подметил одно, регулярно всплывающее в области дизайн-систем и компонентов.

Это насчет разделения ответственности. У веба долгая история разделения структуры, представления и поведения с помощью HTML, CSS и JavaScript. Оно исправно служит нам. Если писать код в таком порядке, добиваясь, чтобы нечто работало (в какой-то мере), прежде чем добавлять следующий слой, результат будет надежным и устойчивым к сбоям.

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

Вместо того, чтобы разделять ответственность по языкам (как HTML, CSS и JavaScript), мы стремимся к модели разделения ответственности на уровне компонентов.

Это очень созвучно тезису, высказанному ранее в презентации Кристиано Растелли.

Разделение ответственности в соответствии с задачей каждого компонента более чем логично… но это не значит, что надо перестать разделять структуру, представление и поведение! Почему бы не делать и то, и другое?

В «традиционном» разделении ответственности в вебе (HTML/CSS/JavaScript) нет ничего, что ограничивает его только простыми страницами. Я бы сказал, что оно как раз лучше всего работает, если применять его на уровне чего-то мелкомасштабного.

В своей статье «Сначала библиотека паттернов: подход к управлению CSS» Рейчел советует начинать каждый компонент с хорошей разметки:

Вам всегда стоит начинать с хорошо структурированной разметки.

Это гарантирует, что ваш контент доступен на самом базовом уровне, но это еще и значит, что вы можете использовать преимущества нормального потока (т.е. самой базовой CSS-раскладки, блоков и строк текста — прим. перев.).

По сути это подход по правилу языка с наименьшими возможностями (чем более мощным языком обрабатываются данные, тем сложнее как-то использовать эти данные в дальнейшем, поэтому если задачу можно решить простым, чисто описательным языком, не надо выбирать сложный процедурный; иногда считается частным случаем принципа минимальных привилегий применительно к выбору языка — прим. перев.). В главе 6 книги «Устойчивый веб-дизайн» я наметил трехэтапный процесс, которым я руководствуюсь при разработке для веба:

  1. Определить основную функциональность
  2. Сделать эту функциональность доступной с помощью самой простой технологии, какой только можно
  3. Добавлять улучшения!

Та глава полна примеров, как применять эти шаги на уровне всего сайта или продукта, но не надо на этом останавливаться:

Этот трехэтапный процесс можно применять и в масштабе отдельных компонентов на странице. «В чем основная функциональность этого компонента? Как мне сделать эту функциональность доступной с помощью наипростейшей технологии? А как теперь я могу ее улучшить?»

У разделения ответственности при создании страниц и при создании компонентов есть еще одно общее преимущество. В случае страниц, вопрос «В чем тут основная функциональность?» поможет вам подобрать хороший URL. Применительно к компонентам этот же вопрос поможет придумать удачное имя… а это то, из чего складывается ядро хорошей дизайн-системы. В своей блестящей книге «Дизайн-системы» Алла рекомендует задавать вопрос «В чем цель?», чтобы добиться хорошего общего языка для всех, кто работает с компонентами.

Мой тезис таков:

  • Разделять структуру, представление и поведение — это хорошо.
  • Разделять интерфейс на компоненты — это хорошо.

Эти идеи не противоречат друг другу. Представлять их как некий взаимоисключающий выбор — всё равно, что говорить «раньше я ел итальянскую еду, но теперь я пью итальянское вино». Они лучше всего работают в комбинации друг с другом.

P.S. Это тоже может быть интересно:

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ваш E-mail не будет опубликован

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.