Комментарии 34

Список не претендует на охват всех достойных библиотек) Я отобрала лишь несколько библиотек, которые интересно сравнить, на мой взгляд.

Самая лучшая библиотека компонентов будет та, которую сам сотворишь, когда у тебя будет времени. А времени нет, вот и надо выбирать из того что уже существует. Начинал с Material Design, попробовал Blueprint, несколько проектов сделал с Semantic UI React, остановился на Ant Design. Она что, «самая-самая»? Да нет! Дело в том, что большинство UI библиотек заточено под мобильники, и если делаешь веб приложение для завода (нпр. планировка производства) или для сети частных клиник (scheduling клиентов, и прочая, и прочая...), т.е. для десктоп, то большинство библиотек будет тебя доставать огромными margin/padding. С Ant можно показать на страничке под сотню компонентов (без излишнего колдовства). То, что мне нужно. Другим, естественно, это может быть не важно. У Ant недостатков хватает, но ведь халява же! Спасибо им! ant.design/components/overview

А вам — удачи с вашим Korus-UI! Будет времени, обязательно попробую. Любознательный же.

P.S.
У вас что, на самом деле нету таблицы (table), или я не сообразил где её найти на esphere.ru?
Спасибо за наводку! Выглядит лаконично, все как я люблю )

Очень удивился, не увидев Анта в посте. Особенно учитывая выделение фактора "поддержка коммерческой компании" как важного.

Спасибо, что поделились своим мнением и опытом


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


По поводу таблицы – у нас библиотека предоставляет обертки для тегов, т.е. для таблицы будут L.Table, L.Tr, L.Td и тд.

Вопрос про расширяемость – если внутренние свойства можно переопределять и подменять, то как при этом гарантировать обратную совместимость? Как делать внутренние рефакторинги, если пользователи на эти элементы как-то завязываются?

Как обычно — чёткое разделение публичного и внутрннего API, семвер, тесты, контракты, тесты на контракты.

Это в теории. А на практике, какой контракт можно оформить вот на это:


Можно написать кастомные стили под имеющуюся вёрстку. Полный список классов в компонентах находится в разделе API-документации (см. атрибут theme).

Фактически, разработчики могут выкинуть и заменить любой CSS на свой собственный. Как это формализовать и протестировать?

Как минимум проверять, что нет неизвестных классов. Если используется css-in-js то средствами тайп-чекера проверять, что переопределяются в клиентском коде только те стили, что занесены в публичный API

А реальный пример можно где-то увидеть?


Из того что я видел, в material ui предлагают переопределения стилей, но все это делается на свой риск и может ломаться в минорных релизах

Проблема обратной совместимости решается тестами. Классы, которые мы предоставляем пользователям, также покрыты тестами.


Расширяемость вы можете использовать на своем проекте, при этом есть возможность подменять внутренние элементы компонентов, сохраняя при этом передаваемые элементу пропсы, в том числе классы:


labelRender={({ elementProps }) => <MyCustomLabel {…elementProps} />}

С labelRender понятно, это популярный паттерн, с ним понятно что делать и как тестировать.


Но у вас еще и вот такой API есть:


<L.CheckBox
  theme={{
    element: 'checkbox__custom-input',
    focused: 'custom-focused',
  }}
>
  Label
</L.CheckBox>

Если я правильно прочитал документацию, то theme.element заменит класс на чекбоксе и удалит все стандартные стили. Это так работает?

Да, все верно. При передаче объекта theme заменяются все дефолтные классы

Ясно. И это API работает как раскиданные грабли.


Стили обычно работают не атомарно, а вместе. Если заменить один класс, то остальные могут развалиться, как например это произошло у вас в ButtonGroup:



У вас есть какая-то долгосрочная стратегия, как уберечь кастомизацию от ломающих изменений?

За выкладывание в открытый доступ конечно плюс, но есть брать факты:
— 7 звезд на гитхабе
— Все контрибьюторы имеют нулевой опыт в опен-сорс(не всегда, но как правило это означает что программирование им просто неинтерестно, люди отсиживают с 9 до 18 за зарплату имея другие интересы по жизни)
— Документация на русском
С такими вводными что-то стоящее создать будет сложно, но в любом случае желаю удачи.
Если не секрет, можете поделиться как принималось решение выложить в Опен-сорс(аргументы за, аргументы против, кто в итоге сказал финальное слово)? Не было ли опасения что спонсор проекта подумает что вы просто осваивали его бюджет 1.5года разрабатывая эту библиотеку?

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


Если говорить о различных затратах, то использование библиотеки в проектах принесло огромное число плюсов и точно оправдало себя. С ее помощью мы решаем оперативнее возникающие блокеры, сокращаем сроки старта и разработки проектов, а это напрямую влияет на лояльность заказчиков, сроки и стоимость. Если же говорить о спонсоре, то тут всё просто – СберКорус и есть спонсор, т.е. это наш внутренний самостоятельный проект.


Решение о выводе в opensource было принято коллегиально, включая ИТ-директора.


Мы не отрицаем, что недостатки есть, мы о них открыто говорим и над ними работаем)
Звезд мало, да, потому что мы только что вышли в opensource и нам еще только предстоит заслужить лояльность и доверие широкого сообщества. Работа над документацией в ближайших планах, это будет первоочередная задача в новом году.


А вот заявление про то, что людям работающим в компании, программирование не интересно, достаточно категорично на мой взгляд) Можете аргументировать?
Какого "опыта в опен-сорс" на ваш взгляд может недоставать сотрудникам компании? В чем это может выражаться?

А сколько составил общий бюджет на разработку этих компонент(в часах, в деньгах)? Сколько еще планируется выделить?
Еще очень бы хотелось бы подробнее узнать про то, как технически делалось такое решение(о выкладывании в опен сорс). Менялись ли трудовые договора с сотрудниками? в них же наверняка условие о конфиденциальности, были ли консультации с юристами и прочее. Я хочу похожее сделать в своей компании(перевести часть компонент на опен сорс), но непонятно как подойти к этому вопросу, как продать идею. Мне кажется при вопросе в лоб, руководство скажет что нельзя. Подобные вопросы кстати часто возникают, буду очень признателен если поделитесь, думаю можете даже еще статью написать :) (только сюда ссылку добавьте)
Про опыт:
— Я посмотрел историю коммитов, они делаются только в рабочие дни
— По профилям — ни у кого нет своих личных проектов со звездами
Но наверное это только начало, и довольно позитивное

Кстати, некоторые компании доступ к своим репозиториям дают сотрудникам только под рабочими аккаунтами и личная и рабочая статистика не пересекается.

Кстати тоже очень интерестный момент. но зачем такое может понадобится для открытого проекта с MIT лицензией?

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

Из определения:
Служебное произведение – это результат интеллектуальной деятельности работника. По умолчанию права на такие произведения принадлежат работодателю. Использование произведения автором, не обладающим соответствующими правами, является незаконным, и работодатель может потребовать компенсацию в суде

Теперь вопрос — чем вообще будет являться коммит в проект с MIT лицензией. Т.е. если вот я возьму их проект на гитхабе с MIT лицензией себе, а потом они придут и скажут что использование такого кода незаконно, галочки на гитхабе(что это MIT) ничего не значат.
Очень интерестные вопросы конечно

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

А можно с вашей либой легко заменить ваши формы, валидации и т. п. на сторонние — formik, finalform или самописные? Если нет, то это большой минус. Это уже бизнес-логика и делать ей вендор-лок очень сомнительное решение.

Конечно, при необходимости можно использовать компоненты библиотеки Korus-UI вместе с другими библиотеками, например, с formik и валидировать через yup.

Хорошая статья. Странно, что в подборку не попали бустрап-библиотеки типа react-bootstrap (18800 звезд) и reactstrap (9700 звезд). Также существует платформа для компонентов bit (12600 звезд)

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

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

Как подвопрос: сколько процентов ресурсов команды планируется тратить на работу с issues и прочими PR от третьих лиц?

У нас в команде не будет разграничения на задачи от внутренних проектов СберКоруса и на задачи от сторонних разработчиков. Со всеми issues и PR будет проводиться обычная работа: определяем актуальность, приоритет, с учетом это планируем состав релиза. Разработка ведется по гибким методологиям, так что есть возможность быстрого реагирования на срочные задачи.


Возвращаясь к вашему вопросу, процент затрачиваемых ресурсов команды будет зависеть от количества запросов со стороны сообщества)

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


Сейчас мы настраиваем работу с учетом того, что теперь проект вышел в opensource. Планов у нас много) Если говорить конкретно, в первую очередь в новом году будем работать над документацией. Также будем разрабатывать новые компоненты)

В Сбере уже есть несколько библиотек. Но каждый пытается сделать свою, даже если она будет хуже ЕФСной или СБОЛовской.
Забыли добавить в сравнение важный параметр а именно размер библиотеки и возможность тришейкинга.
И конкретно ваше решение сильно страдает от отсутствия последнего
Если на какой то страницы мне нужна просто одна кнопка — то пользователю придется выкачать дополнительные 105кб кода в гзипе а браузеру распарсить дополнительные 400кб кода.

Вы конечно заявляете что официальной поддержки мобилок нет(хотя это тоже огромный минус) но с таким размером библиотеки об этом в целом можно забыть.

Почему кстати ui библиотека берет на себя работу по валидации форм тоже не очень понятно. Это явно стоит вынести в отдельный пакет, так как нужно не всем а размер пакета опять же сильно раздувает

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.