Разработчики больше не нужны для релиза. Нужны JSON Schema и Monaco

[aromanchev]

Очень полезная статья 🤝👍

[4heck]

Спасибо

[Saetova]

Отличный кейс. Схема становится единой точкой правды не только для разработки, но и для тестирования👍

[nighthtr]

я правильно понял, что вы изобрели конфигурацию/настройки/параметры?

[badattech]

Они изобрели Contract First

[4heck]

Не претендую прям на изобретение Contract First, но рассказываю кейс из жизни и в какой связке это получилось у нас

[badattech]

Доверенный пользователь - оксюморон.

Схема может быть источником правды, но не источником смысла.

В английском языке есть замечательное слово liability. Любое нововведение требует дополнительных усилий и поддержки.

Не вижу альтернативных решений которые вы рассматривали. Все признаки золотой отвёртки. Скорее всего, просто жмакнули то, что клод пометил как (Recommended) не глядя.

CUE рассматривали?

Кликбейтный заголовок - фу.

PS: а вы не думали о том что контракты могут описывать системные аналитики, а не разработчики?

[4heck]

Спасибо, по делу. Схема не про смысл - да, поэтому рядом живой предпросмотр и что поменял, то и увидел. Альтернативы смотрели - schemaless-хранилище, ветка на клиента, генератор форм вместо редактора, но из статьи вырезал ради объёма

Решение 2023 года, Клод тут ни при чём. CUE не рассматривали, а советуете? Был опыт?

Про аналитиков согласен, цепочка не привязана к TypeScript, исходником может быть что угодно и писать его может кто угодно. У нас просто нет аналитиков 😂

[alexanderniki]

де-то на пути от «сделаем клиенту красиво» до «поддерживаем это в проде» архитектура свернула не туда.

Плохая новость заключается в том, что архитектура тут ни при чем. Хорошая новость в том, что "свернуть туда" практически ничего не стоит. Начать можно с того, чтобы перестать думать в системе понятий "сделать кому-то красиво".

У нас в Getfloorplan она свернула не туда примерно на пятом клиенте, а осознали мы это ближе к сотому.

Так и запишем: коэффициент обучаемости 0.05 :))

[Evelian]

Спасибо за подробный материал! Интересно было узнать про ваш опыт.

Как думаете, насколько такой процесс масштабируется на большую дизайн-систему с сотнями компонентов и большим количеством вариантов и состояний? Не начинает ли объём markdown-правил в какой-то момент сам становиться отдельной системой, которую сложно поддерживать?

[Evelian]

Немного уточню вопрос выше: под «правилами» я скорее имела в виду сам контракт и генерируемую из него JSON Schema. Вы пишете, что сейчас это уже несколько сотен параметров с учётом вложенности. Интересно, не возникает ли по мере дальнейшего роста обратная проблема, когда уже сам контракт приходится отдельно проектировать, структурировать и поддерживать как достаточно сложную систему?

[joeberetta]

Предвижу, что так и будет

Я над подобной схемой (почти рубль в рубль, как у автора) думал, но я больше как платформу для управления конфигами строить планирую

Т.е. пользователь системы заранее собирает в json schema конфиг схему и далее значения

И по своему опыту заложил сразу возможность собирать несколько схем, т.к. модулей/компонентов может быть много (сейчас у меня это все как часть конфига приложения в бд джсонкой и каждый ключ - 1 модуль конфиг - и решил эту штуку вынести в отдельный продукт, ибо у соседних проектов этой фичи как раз не хватает)