Мы живем во времена, когда концепция модель / представление / контроллер становится все более и более устаревшей, что делает компонентный подход новым стандартом для разработки веб-приложений.

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

Что за странности? (вы могли подумать)

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

б) Во втором я вижу, что разработчики не рассматривают компоненты без поведения как компоненты. Они думают, что инкапсуляция разметки того не стоит. Результат - репликация кода разметки и, как следствие, боль в тот момент, когда вам нужно внести изменения в то, что должно быть только в одном месте.

Прежде всего, я хотел бы поделиться концепцией того, что я считаю компонентом. Вот несколько мудрых слов, которые написал Дерик Бейли в одном из своих постов в блоге:

[…] компонентом пользовательского интерфейса веб-приложения может быть панель дисплея, используемая для отображения информации о сотруднике, такой как его имя, адрес электронной почты, идентификатор сотрудника и т. д. Этот компонент может включать кнопки для редактирования сотрудника или другие элементы управления для выполнения других функций.

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

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

Небольшие обязанности

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

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

Гибкость

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

Может быть. Это зависит от того, как вы организовали код, распределенный по домашней странице. Если домашняя страница управляется только одним фрагментом кода, вам, вероятно, придется сделать здесь тонкую операцию. Вы должны удалить часть кода, относящуюся к Weather Card, из этих огромных файлов домашней страницы. Затем вам нужно будет разместить эту точно такую ​​же часть кода в других файлах View.

Готово, хорошо? Еще нет.

Тесты домашней страницы больше не пройдут. Вы только что его изменили. То же самое может произойти и с другими тестами View, если вы их тоже изменили. При компонентном подходе карта погоды является компонентом. Он инкапсулирует всю его разметку, стиль, поведение и тесты. Итак, все, что вам нужно сделать, это переместить простой тег HTML из одного представления в другое.

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

Вы изо всех сил пытаетесь настроить и использовать StorybookJS? У тебя есть альтернатива. Это Питсби. Без правил. Никаких грузчиков. Нет регулярного выражения. Отправьте свои документы с парой очень простых объявлений.