Комментарии 15
А можно ли в вашем решении легко отделить компоненты вашей компании и написать допустим свои для моей? И ваше решение опенсурс?
>> легко отделить компоненты
Да. Так как решение модульное, построенное на Monorepo (git) и npm пакетах, при инициализации можно подключить другой модуль с UI Kit. Фактически, передать другой список компонентов в инициализируюущую функцию.
Из вещей, требующих улучшения: сейчас есть оверхед с адаптерами для компонентов. Для условного компонента Table требуется адаптер, чтобы соединить его (компонент) со слоем DSL. Опираясь на текущий опыт, это кажется избыточным. Работаем над упрощением.
При этом, если использовать только component driven подход, то ваша собственная библиотека компонент соединяется с UIF не дольше, чем работает npm i.
>> Решение опенсурс
Нет. Мы только идём в эту сторону. С точки зрения рабочих потребностей есть задачи, которые бы решились через наш open source. Но и с точки зрения инженерной культуры публикация UIF будет шагом в нужную сторону.
Из вещей, требующих улучшения: сейчас есть оверхед с адаптерами для компонентов. Для условного компонента Table требуется адаптер, чтобы соединить его (компонент) со слоем DSL. Опираясь на текущий опыт, это кажется избыточным. Работаем над упрощением.можно посмотреть как это решено здесь https://github.com/Claus1/unigui . заодно узнать о протоколе.
Спасибо. Выглядит очень интересно.
Также познакомился с вашими статьями Универсальный GUI ~= конец страданиям и Порт GUI фреймворка с Python на Go. Анализ граблей и плюшек.
Из технических нюансов, которые нам важны:
богатая библиотека компонентов на фронте, чтобы в совокупности с продуманными пользовательскими сценариями иметь отличный UX.
возможность создавать UI без DSL, т. к. понимаем, что форму настроек можно (и на наш взгляд нужно) разрабатывать типовым образом, а вот специфичные продуктовые компоненты GeoMap или Chat эффективнее собирать руками на основе UI Kit.
front-to-front взаимодействие плагинов (микрофронтов, интегрированных в host application) для обеспечения кросс-продуктовых сценариев.
Мне понравилось, как вы сформулировали в одном из тредов под вашей статьёй:
>> проще говоря — не думать o GUI и не программить GUI. только реакция на изменение юзером данных
Это ровно та задача, которую мы решаем с помощью DSL. Но повторюсь, здесь, на мой взгляд, очень важно соблюсти баланс, когда DSL помогает нам в типовых операциях и не мешает в специфичных (кастомных). Именно поэтому мы считаем, что DSL применим для «параллельного и перпендикулярного UI», встречающегося сотни раз в проекте. А для всего остального есть UI Kit и component driven подход.
P. S.
>> Подобный GUI хорошо выглядит на простых примерах, где просто эдитки, чекбоксы и так далее. С этими «голый» HTML тоже отлично справляется
Так же утащу комментарий сюда из-под вашей статьи. Ванильный HTML действительно отлично справляется и именно с него я рекомендовал бы начинать разработку фронтенда веб-приложений. Но если вы, скажем, столкнётесь с задачей «а добавь теперь на несколько сотен экранов опциональный значок справки к каждому контролу», вот здесь вам может потребоваться дополнительный инструментарий поверх HTML.
>>вот здесь вам может потребоваться дополнительный инструментарий поверх HTML.
не нужно это, если протокол покрывает все нужные типы данных, и устраивает единый стиль интерфейса (MD). Если на всех экранах нужен составной элемент, делается блок, кладется в blocks папку и используется во всех экранах.
Пример:
Вверху общий блок Parameters. Описан 1 раз в blocks.
```user_edit = Edit('User ID', 1)
tape_length = Edit('Tape length', 20)
inertia = Edit('Update inertia', 0.5)
buffer_length = Edit('Buffer length', 2)
setting_block = Block('Parameters', [ user_edit,
Button("(Re)start", recalc_init, icon = "cloud_sync"), tape_length,
inertia, buffer_length], icon = "settings" )
```
В целом по статье - словоблудие и графомания.
Продукту явно хорошо там где он вырос, стороннему разработчику пользы пока никакой.
Пользы где то вне Касперского от этой поделки скорее всего не будет.
Подозреваю, что разработчик, работая в этой штуке, постепенно забудет, как работать с остальным фронтом и станет "частью корабля, частью команды")
Так что становится неким UIF-разработчиком ради этого - ну такое.
По итогу, продукт является ровно тем чем он и назван в статье - большим толстым и бородатым оверхедом
Много слов ниже, это чтобы дать деталей, подсветил boldом единственный вопрос к вам.
TL;DR:
React 17 (едем на 18), Node.js LTS 6 лет подряд (6, 8, 10, 12, 14 и сейчас 16) и AntD не могу назвать бородатым оверхедом.
Себя могу, а вот штуки выше — нет.
А дальше давайте попробуем разобраться детально.
Во-первых, большое спасибо за ваше мнение и критику.
>> В целом по статье - словоблудие и графомания
Скажите, пожалуйста, о чём хотелось прочитать в первую очередь, но не нашли?
Сама статья задумывалась как приветственная и обзорная.
>> Продукту явно хорошо там где он вырос
Да! При этом для нас основной метрикой является не хорошо ли продукту, то есть UIFу. А хорошо ли продуктам, которые разрабатываются с использованием UIF.
А центральной метрикой является достигаются ли бизнес-потребности. Приведу только 2 примера через призму технологий:
Код получается дешевле в поддержке или нет?
Разработчикам проще писать сложные интеграционные сценарии?
>> Подозреваю, что разработчик, работая в этой штуке, постепенно забудет, как работать с остальным фронтом и станет "частью корабля, частью команды")
>> Так что становится неким UIF-разработчиком ради этого - ну такое.
Это очень классное замечание, кмк.
Именно поэтому весь трюк в том, что никаким UIF-разработчиком вам становится не нужно.
UIF — это набор in-house npm пакетов, построенных вокруг Open Source, и API для интеграции веб-приложенек (читай кросс-продуктовое взаимодействие в одной вкладке).
Давайте приведу несколько областей, входящих в состав UIF:
UI Kit
Это React, AntD, Styled Components и Storybook. Смотрим в сторону Style Dictionary.
Валидация данных
Это пакет validator + набор специфичных продуктовых правил валидации + единый интерфейс для взаимодействия (чтобы оставить платформе контроль за имплементацией)
Observability
Это OpenTelemtry: Jaeger, Prometheus и json-строки
Поэтому у UIF нет (и не ставилось) задачи переизобрести.
Ставилась задачи предкофигурировать и интегрировать. Плюс быстрое вкатывание в проект.
Есть ли оверхеды? Блин, конечно да.
Код написанный вчера — уже легаси. А если ещё и с претензией на абстракции..
Как мы с этим работаем: учимся и внимательно слушаем. Так появился стрим Experts Committe для обсуждения и принятия решений. Описал ниже.
>> стороннему разработчику пользы пока никакой.
>> Пользы где то вне Касперского от этой поделки скорее всего не будет.
Почему решили написать и в чём я вижу пользу:
Рассказать о том, что у нас есть и как устроено.
Получить обратную связь и внести корректировки в наши решения.
Выйти в Open Source. Действительно, выложив наш UI Kit мы никого не удивим, но облегчим интеграцию с нашими продуктами — раз. И дадим ещё примеров хороших инженерных практик — два.
А вот наша плагинная архитектура с возможностью кросс-продуктовой интеграции и low code подход для типовых UI может быть полезен и вне Kaspersky.
Так как третье пока In Progress, я посчитал, что 1 и 2 – этого достаточно для публикации и это ровно то, что мы делаем в сообществе.
>> По итогу, продукт является ровно тем чем он и назван в статье - большим толстым и бородатым оверхедом
Нет, нет и ещё раз нет.
Мы могли бы быть там. Прям все шансы имели.
Если бы не опирались на опыт других и сами бы кое-чего не понимали в веб-разработке.
Чтобы митигировать этот риск, очень опасный и дорогой риск уйти в сторону «своего болота», у нас есть 3 простых правила:
Можешь сделать на ванильном js / ts? Сделай.
Можешь сделать, используя Open Source? Сделай.
Не хватает 1 и 2? Приноси PR или RFC в UIF Experts Committee. Это делегаты от продуктовых команд из разных направлений разработки. Лиды, архитекторы, старшие разработчики, пишущие на разном (JS / TS, Node.js / Go / .Net / C++, React / Angular / Vue), проведут ревью, накидают комментариев и уже потом решение попадёт в основной транк. Разумеется, ребята из гошечки или плюсеры будут смотреть RFC микросервисного шасси для Node.js и вряд ли аддон для сторибука.
При том, что по сути я, лично, с вами полностью согласен, по форме можно было и помягче выразится. Художника обидеть может каждый. Люди стараются, делятся опытом... это не словоблудие.
Но в целом - да, выглядит все довольно громоздко и под капотом абсолютно тривиальный стек.
>> абсолютно тривиальный стек
Да!
Руль на понятном месте, педали на понятном месте. Сели и поехали. Это ровно то, к чему мы стремились.
>> выглядит все довольно громоздко
Я понял, что нужны примеры кода, а лучше открытый репозиторий. Работаем над этим.
Но пока попробую на тех диаграммах, которые есть под рукой.
UIF — это буквально 3 слоя:
Использовать можно только UI Kit, можно так же работу с формами и DSL, а можно всю плагинную архитектуру.
И теперь давайте разберём use cases:
Разработка standalone веб-приложения — create-react-app.
Или любой другой скаффолдинг для любимого стека.
Разработка микрофронтов: Module Federation или single-spa / qiankun.
Разработка большого веб-приложения, состоящего из множества маленьких плагинов (представителей продуктов), которые должны между собой:
взаимодействовать
быть похожими друг на друга
Вот для третьего пункта и нужен UIF.
Таким образом, UIF, состоящий из UI Kit, слоя работы с формами и плагинной архитектуры, используется в следующих случаях:
UIF-based Web App
Веб-интерфейс продукта полностью построен на UIF, включая использование UI Kit, форм, навигации и т. д.
UIF Plugin
Продуктовый плагин, разработанный на UIF и запускающийся в Host App.
Bundle Plugin (for Non-UIF Web App)
Плагин, разработанный на UIF и запускающийся в Web App.
Благодаря данному кейсу можно разрабатывать на UIF в существующем проекте, интегрируя UIF-код в существующую кодовую базу.
В дальнейшем весь код Bundle Plugin, при необходимости, можно перенести в единый UI (UIF-based Web App).
UI Components only
Продукт использует только библиотеку компонентов из UIF.
То есть продукт выглядит идентично другим решениям, но UIF не используется как интеграционная платформа.
Крутая штука, спасибо за овервью. Есть несколько вопросов:
Когда планируете в open source? Хочется пощупать :)
Возможно ли в визуальном редакторе настраивать связи между компонентами и добавлять динамику? Ну например, есть компонент таблички, хочу взять данные с API и засунуть их туда, прикрутить пагинацию и тд, без девов. (Ну или сделать простой toggle и тд)
Поделитесь скриншотом редактора?
Это облако какое-то ?
Микрофронты для всех. Как мы построили платформу UIF, и что под капотом