Comments 15
Спасибо, интересный подход, хотя кажется избыточным.
А каким образом происходит наполнение json на бэке для получения в mobile app (важна ведь последовательность элементов, положение относительно друг друга и т.д.), есть некий фронт для проверки получившегося в результате UI?
p.s. "Если заменить значение на end, то элементы сдвинутся к правому краю" видимо нужно поправить картинку с alignment.
Даже такая, казалось бы, избыточная функциональность часто требует расширения, чтобы выпускать фичи без релиза :)
Сейчас JSON составляет системный аналитик, опираясь на JSON-схемы и документацию по каждому элементу. Для проверки он использует preview-приложения на iOS и Android, где в рантайме можно ввести JSON и увидеть его отображение (либо ошибку с описанием, какой элемент не парсится). Также у нас в разработке механизм генерации этих JSON-ов по фигме с макетами.
Иллюстрация к alignment = end под текстом, там элементы как раз сдвинуты к правому краю :)
Спасибо, а после того, как аналитик разработал json, что он делает - отдает json бэкендеру или сам загружает на бэк? Как json попадает на бэк, вручную кладут или есть инструмент для этого? Кроме того, layout подразумевает иерархию объектов, как она выглядит в итоге, один большой json, со всеми зависимостями?
p.s.
Про alignment я имею ввиду, что у вас картинка с json одинаковая: "algnment" : "fill" для обоих примеров, а должна быть "alignment" : "end" во втором.
Тоже интересен этот момент, так как по опыту использования data driven ui, самое сложное место это стык бекенда и вьюшек на приложении. Чтобы написать вьюшки нужно знать нуьюнасы приложения и как этот json парсится приложением, с другой стороны чтобы бекенд отдвал этот json его нужно как то разместить на бекенде, где в зависимости от логики приложения будет генерится этот json
Все нюансы мы стараемся сразу описать в документации к каждой сущности SDUI, там же храним примеры JSON-ов для типовых версток. Если вдруг аналитик столкнулся с некорректной верстой и дока ему не помогла, то он уже идет за помощью к мейнтейнерам Server-Driven UI (у нас их по 2 человека на каждую платформу)
Сейчас JSON передается на бэк, а бэкендер вручную собирает модель через конфигурацию. Планируем скоро зарелизить админку, где достаточно будет залить готовый JSON, и по имени фичи будет собираться объект, учитывая версии клиента/элементов.
Насчет layout, да, это один большой JSON со всеми зависимостями. Составлять такой JSON может быть больно, но зато time to market сокращается значительно :)
Приветствую коллег по подходу.
Использую data-driven UI в приложениях последние 6 лет.
Рисую UI на базе расширямых компонентов, пропертями, описанными в базе и доступными через UI.
Получается: мобильные, десктопные (web-app), browser extension.
Небольшие дополениня, как то:
- data-driven databases definition
- data-driven DB Tables definition
- data-driven server-side logic (генерация данных и обработка клиенских запросов к базе)
Есть проблемы, но в целом приложения получаются надежными (ссылочная целостность не дает ломаться генерации клиентской и серверной части).
Видимо data-driven UI это то, что нельзя просто так взять и внедрить со старта - компания до него может только дорасти. Можно использовать как маркер уровня технической зрелости. Сам же подход стар как мир: TCL/TK, UIML, XAML, XUL, BEMJSON, QML..
Супер! Спасибо за хорошо изложенную информацию!)
Как катить фичи без релизов. Часть 2: про низкоуровневый Server Driven UI