Comments 7
Есть готовые UI библиотеки с интеграцией в React, Vue и другие фреймворки. Можно было взять их и стилизовать под себя. Почему так не захотели?
Только кашерное/православное/импортозамещённое. Или просто - я так хочу.
?
Можно, мы как раз используем некоторые готовые UI библиотеки для наших внутренних проектов.
А для основного продукта не можем, потому что он постоянно развивается. У нас десятки фичей летят на прод каждую неделю. Каждая из которых может как добавить что-то, так и поменять внешний/вид концепцию. Если использовать готовое решение как есть, то мы будем сильно ограничены.
Есть вариант с добавлением абстракции поверх готового решения, чтобы можно было подсунуть другую библиотеку. Вариант ок, но мы не знаем куда, как часто и как долго будет это готовое решение развиваться. А на полноценное участие в развитии готовой библиотеки, в рамках open source, у нас пока нет возможностей, да и если бы был, у нас продукт технологически развивается медленее.
Остается вариант с форком. Форкнуть ради того, чтобы все выпилить. Все-равно надо передизайнить под себя.
Компоненты должны были работать с разными инструментами, поскольку в
компании есть проекты на TypeScript, на React в связке с Redux или MobX,
на Vue, несколько приложений на Next.js, лендинги в Tilda.
Работа с более чем одним фреймворком - боль. Для полного набора не хватает angular и svelte :)
В очередной раз подтвердил свои наблюдения - что делать общие библиотеки ui-компонентов - зло, и надеятся что оно там что-то кому-то когда-то облегчит жизнь - себя обманывать и оправдывать прожигание ресурсов. Усложнит жизнь - очень вероятно, но врятли облегчит. Это самое последнее про что нужно думать, только если уже совсем "делать нечего" и нужно освоить бюджет и время бизнеса.
каждый дубль элемента — модальное окно, кнопку, инпут — приходилось поддерживать отдельно, на это тратились ресурсы.
Неужели много "ресурсов" тратилось?. Дизайнер решил поменять бордер-радиус у кнопки на 4рх. Создал таску, оповестил всех в общем чате, етс - каждая команда взяла и сделала это у себя в проекте. Это просто, быстро, независимо, понятно и прогнозируемо. Ответственность не размывается. Нет high cohesion. Потом, опа, дизайнер решил в одном проекте чтоб кнопки были красные, а в другом синие.. команды реализовали это отдельно по проектам, не будет мук совести при добавлении if-а в общую библиотеку. Также такой подход легко переживает период смены главных дизайнеров (как правило раз в пару лет) и очередных глобальных редизайнов.
Мой поинт в том, что копи-пастить ui между проектами можно, это меньшее зло, если зло вообще.
Скорее проблема в том, что нет общего главного дизайнера-ревьювера, который бы дисциплинированно контролил консистеность дизайн-системы между проектами, и раздавал бы таски где и что подправить. Да это была бы обычная рутинная не автоматизированная работа.. невелика беда. Да и работу эту условно на джунов можно скидывать.
Как же я понимаю вас.
Мы столкнулись с аналогичными проблемами, при развитии своего продукта. Попытка расширить собственные компоненты, которые были написаны разными руками в разное время - оказалось бессмысленной. За месяц мигрировали все приложение на MUI. Все разногласия с дизайнерами заканчиваются там, где нет компонента из MUI для Figma. Любые кастомные контролы мы теперь просто реджектим.
Идея в том, что если разработчики, следуя строгим правилам того фреймворка, в котором работают могут двигать продукт, то почему дизайнеры не могут работать в оговоренных рамках? Почему разработчики должны обслуживать любое "opinioned meaning" дизайнеров, просто по их желанию? Если вы двигаете продукт, то ограничения - благо. Для всех.
Сделали библиотеку компонентов, но пришлось переделывать. Почему так вышло и чем дело кончилось