Комментарии 22
Изменений бы потребовалось в три раза меньше, если бы карточку переиспользовали.
Возможно, это не очень подходит к фронтэнду, но есть такое правило: принцип DRY нельзя бездумно применять при работе с кодом, который пишется на основании бизнес-требований. Если у вас единственный сайт, то да, имеет смысл один компонент. Если сайтов несколько или несколько логически несвязанных разделов, рано или поздно от бизнеса может прилететь требование изменить только одно из мест. Конечно, карточка — достаточно простой компонент, чтобы от этого были проблемы, но если компонент будет посложнее, это может привести в итоге к трудноподдерживаемому коду.
Спасибо за комментарий! Я думаю, вы правы. Большую роль играет атомарность компонентов и сложность в том, чтобы определить, когда делить на компоненты, а когда нет. Бывает и так (и, по моему опыту, это происходит чаще), что код трудно поддерживать потому, что нет возможности поменять несколько мест сразу.
Возможно в случае нескольких проектов на одной библиотеке, стоит смотреть в сторону дизайн-системы и организовывать компоненты на двух уровнях: простые тупые на уровне дизайн-системы и умные на уровне проекта. Как бы библиотека в библиотеке.
Feel free Можете использовать любое удобное название))
Мне лично слова "глупый" и "тупой" кажутся наиболее подходящими, потому что отражают отсутствие привязки к контексту. Всё-таки "простой" это немного о другом. Но тут как вам удобнее))
Ещё есть такая статья по теме различий этих двух типов компонентов, там терминология немного другая.
Только вот обычно для такого противопоставление компонентов программы, как в статье, в англоязычных технических текстах чаще, по моему наблюдению, используется альтернатива dumb-smart. И вот подобрать другое слово для перевода dumb я лично затрудняюсь: в частности, прямое значение — «немой» — тут явно не годится.
Да, буквально там так и написано)) дизайнеры редко используют этот подход, к сожалению
Дело не в инструментах, а в подходах и командной работе.
Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.
Однажды мы решаем разом модернизировать все карточки — сделать изображения круглыми. Модно!
Плохой пример. Часто встречал требование вида,
— вот тут, тут и тут круглое. А вот тут оставить как было. Это же не долго, час не больше.
— Но… Это же один и тот же компонент!
По этому разбиение на компоненты как предлагаете вы это палка о двух концах. Для себя я лично решил что stateless это всякие примитивы. А умные компоненты можно делать вообще без рендерера, чисто базовый с abstract методами. Если это прям так необходимо.
Хотя тут скорее всего от проекта зависит.
MainView — главная «рамочка» карточки
ImageView — картинка
HeaderView — заголовок
DescritionView — описание
PriceView — цена
ControlView — кнопочки
и т.д.
Хотим картинку в круге? Меняем ImageView.
Нужно в карточку добавить сводную информацию о заказах? Создаём SummaryView.
Зачем делать тупую рыбу-заглушку?
В заглушке предусмотрены разные кнопочки или их отсутствие, и может не быть цены.
Это гибкий шаблон для применения в разных ситуациях, предусматривающий много разных состояний и кейсов
Очень понравилась статья, созвучные мысли!
Думаю, что можно попытаться все это дело еще раз обобщить и сказать, что уровней может быть не 2, а больше. Именно больше, а не 3, тк в зависимости от размера проекта глубина ветвления может быть больше или меньше. На простых проектах типа мвп чаще всего и 1 уровня хватает.
Поясню. Оттолкнусь от вашего примера с изменением формы окошек. Можно начать с того, что просто определить самый базовый компонент - окошко. С нужными скруглениями, с нужной тень или окантовкой. Дальше можно на основании этого базового компонента сделать ряд менее базовых или, в вашей терминологии, тупых компонентов: диалоговые окна, рекламные флйеры и что угодно еще.
Получается уже три уровня. Но я с легкостью вижу и большую глубину вложенности или композиции. Все зависит от масштаба проекта и ставке на живой, экспериментирующий дизайн.
И я согласен с вами в мысли, что это очень даже тема для развития дизайнеров. Потому что одна из основных проблем в разработке — понять что делать гибким, а что не делать. И если часть этих задач сможет брать на себя дизайнер, хотя бы в рамках продумывания компонентов UI, это уже облегчит работу программистам и ускорит работу над UI слоем. Сюда же в копилку то, что дизайнеры ближе к конечным клиентам, к продукту, к продактам, поэтому они лучше себе представляют где добавить гибкости, а где можно навалять и так сойдет.
Единственное, что тут, наверное, дизайнеру хорошо бы понимать и специфику платформы, с которой он работает. Причем желательно еще и ограничения и возможности конкретной используемой технологии для создания UI.
И швец, и жнец, и на дуде игрец, получается, нужен. Или, говоря современным языком, человек-расчёска :)
Тупые и умные компоненты