Comments 34
А вам — удачи с вашим 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 заменит класс на чекбоксе и удалит все стандартные стили. Это так работает?
— 7 звезд на гитхабе
— Все контрибьюторы имеют нулевой опыт в опен-сорс(не всегда, но как правило это означает что программирование им просто неинтерестно, люди отсиживают с 9 до 18 за зарплату имея другие интересы по жизни)
— Документация на русском
С такими вводными что-то стоящее создать будет сложно, но в любом случае желаю удачи.
Если не секрет, можете поделиться как принималось решение выложить в Опен-сорс(аргументы за, аргументы против, кто в итоге сказал финальное слово)? Не было ли опасения что спонсор проекта подумает что вы просто осваивали его бюджет 1.5года разрабатывая эту библиотеку?
Секрета нет) Мы для себя создали действительно эффективный инструмент и осознали, что уровень зрелости компании позволяет делиться наработками с сообществом.
Если говорить о различных затратах, то использование библиотеки в проектах принесло огромное число плюсов и точно оправдало себя. С ее помощью мы решаем оперативнее возникающие блокеры, сокращаем сроки старта и разработки проектов, а это напрямую влияет на лояльность заказчиков, сроки и стоимость. Если же говорить о спонсоре, то тут всё просто – СберКорус и есть спонсор, т.е. это наш внутренний самостоятельный проект.
Решение о выводе в opensource было принято коллегиально, включая ИТ-директора.
Мы не отрицаем, что недостатки есть, мы о них открыто говорим и над ними работаем)
Звезд мало, да, потому что мы только что вышли в opensource и нам еще только предстоит заслужить лояльность и доверие широкого сообщества. Работа над документацией в ближайших планах, это будет первоочередная задача в новом году.
А вот заявление про то, что людям работающим в компании, программирование не интересно, достаточно категорично на мой взгляд) Можете аргументировать?
Какого "опыта в опен-сорс" на ваш взгляд может недоставать сотрудникам компании? В чем это может выражаться?
Еще очень бы хотелось бы подробнее узнать про то, как технически делалось такое решение(о выкладывании в опен сорс). Менялись ли трудовые договора с сотрудниками? в них же наверняка условие о конфиденциальности, были ли консультации с юристами и прочее. Я хочу похожее сделать в своей компании(перевести часть компонент на опен сорс), но непонятно как подойти к этому вопросу, как продать идею. Мне кажется при вопросе в лоб, руководство скажет что нельзя. Подобные вопросы кстати часто возникают, буду очень признателен если поделитесь, думаю можете даже еще статью написать :) (только сюда ссылку добавьте)
Про опыт:
— Я посмотрел историю коммитов, они делаются только в рабочие дни
— По профилям — ни у кого нет своих личных проектов со звездами
Но наверное это только начало, и довольно позитивное
Кстати, некоторые компании доступ к своим репозиториям дают сотрудникам только под рабочими аккаунтами и личная и рабочая статистика не пересекается.
Общая корпоративная политика, независимая от проекта, в том числе для более простого доказывания факта, что контрибутил человек в рамках трудовых обязанностей, и проект является служебными произведением.
Служебное произведение – это результат интеллектуальной деятельности работника. По умолчанию права на такие произведения принадлежат работодателю. Использование произведения автором, не обладающим соответствующими правами, является незаконным, и работодатель может потребовать компенсацию в суде
Теперь вопрос — чем вообще будет являться коммит в проект с MIT лицензией. Т.е. если вот я возьму их проект на гитхабе с MIT лицензией себе, а потом они придут и скажут что использование такого кода незаконно, галочки на гитхабе(что это MIT) ничего не значат.
Очень интерестные вопросы конечно
А можно с вашей либой легко заменить ваши формы, валидации и т. п. на сторонние — formik, finalform или самописные? Если нет, то это большой минус. Это уже бизнес-логика и делать ей вендор-лок очень сомнительное решение.
Опенсорс это не столько выложить код, сколько целенаправленная работа с сообществом. Маркетинг, евангелистика,
документация, обучение, конференции и т.д. Что в общем-то затратно, особо в высококонкурентных нишах. Нередко интересы опенсорс проекта идут вразрез с текущими коммерческими задачами компании. Об это регулярно ломается куча начинаний. Каковы планы у вашей команды и вашей компании?
Как подвопрос: сколько процентов ресурсов команды планируется тратить на работу с issues и прочими PR от третьих лиц?
У нас в команде не будет разграничения на задачи от внутренних проектов СберКоруса и на задачи от сторонних разработчиков. Со всеми issues и PR будет проводиться обычная работа: определяем актуальность, приоритет, с учетом это планируем состав релиза. Разработка ведется по гибким методологиям, так что есть возможность быстрого реагирования на срочные задачи.
Возвращаясь к вашему вопросу, процент затрачиваемых ресурсов команды будет зависеть от количества запросов со стороны сообщества)
Вы абсолютно правы, это большая работа. Поэтому есть определенные преимущества, когда работа над opensource проектом ведется в рамках компании. Есть бюджет, есть возможность планирования, есть ресурсы.
Сейчас мы настраиваем работу с учетом того, что теперь проект вышел в opensource. Планов у нас много) Если говорить конкретно, в первую очередь в новом году будем работать над документацией. Также будем разрабатывать новые компоненты)
Приятно что есть валидация)
И конкретно ваше решение сильно страдает от отсутствия последнего
Если на какой то страницы мне нужна просто одна кнопка — то пользователю придется выкачать дополнительные 105кб кода в гзипе а браузеру распарсить дополнительные 400кб кода.
Вы конечно заявляете что официальной поддержки мобилок нет(хотя это тоже огромный минус) но с таким размером библиотеки об этом в целом можно забыть.
Почему кстати ui библиотека берет на себя работу по валидации форм тоже не очень понятно. Это явно стоит вынести в отдельный пакет, так как нужно не всем а размер пакета опять же сильно раздувает
Что выбрать в качестве библиотеки компонентов для React-проекта