Комментарии 10
преимущество UI-кита — что с его помощью можно быстро менять интерфейсы сразу в нескольких приложениях, при этом используя единый источник истины
такое хоть раз, хоть у кого-то было?..)
обычно ж, вот здесь, конкретно в этом одном месте - нужно чтоб было не так как везде..) привет дополнительный if/props, прощай идеальная абстракция.
перестать писать компоненты в рамках проекта и сразу выносить их в UI-кит
Думаю, чтобы выносить компонент в ui-kit - он должен сначала "пожить" в боевых условиях, доказать свою стабильность и право быть там. И потом, через время, когда есть уже достаточно оснований, в рамках отдельной задачи - можно выносить компонент в общий кит, с минимальными рисками протечки абстракции (т.к. уже понятно - что абстрагировать, а что нет).
такое хоть раз, хоть у кого-то было?..)
Вы не поверите, но да, в рамках одного продукта может быть несколько приложений разделенных по зонам ответственности ПМ и команд разработки, именно в таком случае это будет достаточно удобный инструмент.
Вы работаете в компании и делаете продукты на заказ, тут конечно подойдет конкретный подход, а именно хедлес, но своя библиотека опять оправдывает себя, так как позволяет часто использовать уже готовые логические компоненты.
Интересная проблема - когда команды не синхронизированы с точки зрения используемых инструментов, у нас было так что в какой то момент времени использовали React от 16 до 18й версии, в контексте такого случая - общая библиотека компонентов это тоже проблема. Так как сначала всем надо договориться и переехать на использование одной версии библиотеки, что является сжиганием часов на рефакторинг того, что и так работает. Ну и бизнес такое не очень уже любит.
Думаю, чтобы выносить компонент в ui-kit - он должен сначала "пожить" в боевых условиях, доказать свою стабильность и право быть там.
Холиварненько... но компонент может пожить и в UI Kit и доказать что он его достоин, в таком случае даже переносить ничего не нужно. И если код библиотеки доступен многим командам в рамках компании, то шанс что найдут как доработать и поправить сильно выше, нежели он будет лежать просто в своем проекте с которым работает полтора разработчика.
И если код библиотеки доступен многим командам в рамках компании, то шанс что найдут как доработать и поправить сильно выше
А также шанс "сильно выше " что поломают чиня (дорабатывая).
Вы не поверите, но да
я больше про кейс, вот есть у нас primaryColor=blue. Прошло время. Хоть когда-нибудь, у кого-нибудь было - чтоб пришёл дизайнер\маркетолог и сказал - "так, с понедельника у нас primaryColor должен быть красным!". И дев-ы такие радостно - "пустяки, только значение в переменной обновить".
Обычно ж, там пусть будет синий как было. А тут чуть краснее. И вот уже primaryColor - непонятно зачем было и создавать, и что именно он означает непонятно. Нужно заводить primaryColor-v2 или как?)
Это не только с цветом, а вообще с любым компонентом.
Именно поэтому мы привели пример про использование переменных, var(--primaryColor) может меняться в рамках проектов, а для компонента изменений не будет. Причем primaryColor может устанавливаться через вариативность типа кнопки и это может работать не только с цветом.
Как вы уже упоминали выше, без оснований и тестов написать что то хорошее сразу не получится, но я бы рекомендовал пробовать, а не опускать руки со словами "Все тлен....".
> я больше про кейс, вот есть у нас primaryColor=blue. Прошло время. Хоть когда-нибудь, у кого-нибудь было - чтоб пришёл дизайнер\маркетолог и сказал - "так, с понедельника у нас primaryColor должен быть красным!"
Конечно было, как минимум три раза в своей карьере помню. Раз было не радикальное изменение (вспомогательные менять не пришлось), раз - прям радикальное (с жёлтого на синий), вот оно показало, кто где срал хардкодил. Ну и светлые / темные темы, где и основной, и вспомогательные требуют коррекции.
У меня было буквально пару недель назад. Случился ребрендинг и почти все цвета поменялись. Мигрировать на новый дизайн получилось где-то за час всего)
хз, как можно обновлять дизайн 10мин\час. Может мы закладываем разные понятия в "обновление дизайна".
У нас, например, такая история. Продуктовая компания. Примерно 10 фронт-проектов. Возраст каждого проекта примерно от 10-ти до 2-х лет. Примерно раз в два года меняется главный маркетолог.. соответсвенно пытается как-то показать свою нужность.. соответственно перетрушиваются дизайнеры и дизайны. Соответсвенно каждый проект перманентно находится на каком-то этапе обновления какой-то версии какого-то дизайна. Где-то кнопки перекрасить, а где-то полностью макет и юзер-стори меняется.
И всё это точечно в разных проектах, в разных частях, в разные моменты времени. На это всё я выделяю примерно 15% ресурсов джунов.
Самое главное, что оно +- всё-равно выглядет одинаково (first look and feel), и какие-то мелкие различия на продуктовые метрики не влияет никак. Т.к. ценность продукта не в дизайне.
И вот в нашем кейсе иметь ui-kit на всю компанию на все проекты - это иметь high-coupling, + ментальные боли при принятии решений (добавить if.. или выность куда-то?).
Мой поинт в том, что имеет смысл заводить ui-кит - только если ваш продукт и есть сам UI (в том или ином проявлении). В иных случаях - пингануть лидов в чатике - чтоб те перекрасили у себя кнопки в проектах - проще, быстрее и надёжнее.
И второй мой поинт - копипастить ui между проектами, и подгонять под конкретный проект - не так страшно. Это не логика, и не структуры данных, это всего-лишь ui, который в каждом конкретном месте может чуть-чуть отличаться (такова природа художников - не стоит ожидать от них порядка.. и это нормально).
Полный гайд по UI-китам: как их создавать, подключать и ничего не бояться