Pull to refresh

Comments 22

Изменений бы потребовалось в три раза меньше, если бы карточку переиспользовали.

Возможно, это не очень подходит к фронтэнду, но есть такое правило: принцип DRY нельзя бездумно применять при работе с кодом, который пишется на основании бизнес-требований. Если у вас единственный сайт, то да, имеет смысл один компонент. Если сайтов несколько или несколько логически несвязанных разделов, рано или поздно от бизнеса может прилететь требование изменить только одно из мест. Конечно, карточка — достаточно простой компонент, чтобы от этого были проблемы, но если компонент будет посложнее, это может привести в итоге к трудноподдерживаемому коду.

Спасибо за комментарий! Я думаю, вы правы. Большую роль играет атомарность компонентов и сложность в том, чтобы определить, когда делить на компоненты, а когда нет. Бывает и так (и, по моему опыту, это происходит чаще), что код трудно поддерживать потому, что нет возможности поменять несколько мест сразу.


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

А можно «тупой» заменить на что-то более благозвучное? Ну, к примеру, «простой»?

Feel free Можете использовать любое удобное название))

Это скорее вопрос, сам немного затупил, как адекватно перевести dummy на русский в данном контексте.

Мне лично слова "глупый" и "тупой" кажутся наиболее подходящими, потому что отражают отсутствие привязки к контексту. Всё-таки "простой" это немного о другом. Но тут как вам удобнее))

В среде React «тупые» компоненты обычно называют «глупыми». Например, тут.

Ещё есть такая статья по теме различий этих двух типов компонентов, там терминология немного другая.
Со словом dummy ничего особо сложного нет: вполне можно использовать его прямое значение — «модель, макет». И «тупые компоненты» можно назвать, например, «компонентами-макетами».
Только вот обычно для такого противопоставление компонентов программы, как в статье, в англоязычных технических текстах чаще, по моему наблюдению, используется альтернатива dumb-smart. И вот подобрать другое слово для перевода dumb я лично затрудняюсь: в частности, прямое значение — «немой» — тут явно не годится.
в фигме нормальные названия component — instance.
по русски можно называть общий/абстрактный и частный случай

Да, буквально там так и написано)) дизайнеры редко используют этот подход, к сожалению

Лично мне странно, что у вас разработкой переиспользуемых компонентов занимаются дизайнеры. По опыту работы в другой, сходной области — разработка UI программ для Windows на Delphi — я склонен считать, что разработка повторно используемых компонентов — это задача программистов. Потому как имеющиеся в языках с классическим ООП (инкапсуляция-наследование-полиморфизм), типа Delphi инструменты для этого — это программистские инструменты. Про используемые у вас инструменты я несколько не в курсе, но полагаю, что ситуция сходная.

Дело не в инструментах, а в подходах и командной работе.
Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.

Однажды мы решаем разом модернизировать все карточки — сделать изображения круглыми. Модно!

Плохой пример. Часто встречал требование вида,
— вот тут, тут и тут круглое. А вот тут оставить как было. Это же не долго, час не больше.
— Но… Это же один и тот же компонент!
По этому разбиение на компоненты как предлагаете вы это палка о двух концах. Для себя я лично решил что stateless это всякие примитивы. А умные компоненты можно делать вообще без рендерера, чисто базовый с abstract методами. Если это прям так необходимо.
Хотя тут скорее всего от проекта зависит.

Абсолютно согласна, от проекта и от того насколько атомарны компоненты. Атомарность это ещё одна большая и болезненная тема дизайна и разработки интерфейсов в принципе.

Я, наверное, не до конца понял, но для меня карточка состоит из:
MainView — главная «рамочка» карточки
ImageView — картинка
HeaderView — заголовок
DescritionView — описание
PriceView — цена
ControlView — кнопочки
и т.д.

Хотим картинку в круге? Меняем ImageView.
Нужно в карточку добавить сводную информацию о заказах? Создаём SummaryView.
Зачем делать тупую рыбу-заглушку?

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

А если все эти кнопочки не нужны, то куда они деваются? Остаются в коде как мусор?
Они остаются в коде (и в дизайне) как элементы компонента, готового к изменениям при необходимости. Если вас беспокоит проблема неиспользуемого кода, то, насколько мне известно, Storybook позволяет снизить его количество засчет хранения компонентов отдельно от кода продукта. Но тут меня разработчики могут поправить

Очень понравилась статья, созвучные мысли!

Думаю, что можно попытаться все это дело еще раз обобщить и сказать, что уровней может быть не 2, а больше. Именно больше, а не 3, тк в зависимости от размера проекта глубина ветвления может быть больше или меньше. На простых проектах типа мвп чаще всего и 1 уровня хватает.

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

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

И я согласен с вами в мысли, что это очень даже тема для развития дизайнеров. Потому что одна из основных проблем в разработке — понять что делать гибким, а что не делать. И если часть этих задач сможет брать на себя дизайнер, хотя бы в рамках продумывания компонентов UI, это уже облегчит работу программистам и ускорит работу над UI слоем. Сюда же в копилку то, что дизайнеры ближе к конечным клиентам, к продукту, к продактам, поэтому они лучше себе представляют где добавить гибкости, а где можно навалять и так сойдет.

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

И швец, и жнец, и на дуде игрец, получается, нужен. Или, говоря современным языком, человек-расчёска :)

То, что вы описываете - это Atomic Design подход, когда из простых элементов составляются более сложные. В статье важно другое – что в UI-ките компоненты остаются отвязаными от бизнес-логики (тупыми), независимо от их сложности.

Only those users with full accounts are able to leave comments. Log in, please.