Каталог компонентов
Component Catalog — список компонентов FlutterFlow, которые GenUI может показать прямо в переписке. Без каталога чат работает и вызывает инструменты, но рисовать ему нечего.
Для каждого компонента GenUI собирает описание:
- имя компонента;
- описание компонента;
- имена параметров;
- типы параметров;
- обязательность;
- описания параметров.
Насколько удачно модель выбирает компонент, ровно настолько зависит от того, как вы его назвали и описали.
Требования к компоненту
Компонент должен сериализоваться
У компонентов каталога не может быть параметров-действий: GenUI умеет передавать в компонент структурированные данные, но не функции обратного вызова.
Поддерживаемые типы параметров
StringintdoubleboolColorDateTimeTimestampRangeLatLngGooglePlaceJSONDataStructEnum- строковые типы путей к медиа:
ImagePath,VideoPath,AudioPath,MediaPath List<T>из перечисленных типов
Обязательным сложным параметрам нужно значение по умолчанию
Если параметр не может быть null и имеет один из типов:
ColorDateTimeTimestampRangeLatLngGooglePlaceDataStructJSON
то нужно либо задать ему значение по умолчанию, либо сделать его необязательным.
Скажем, у компонента EventCard есть обязательный eventDate: DateTime — без значения по умолчанию проверка каталога отклонит компонент. Причина проста: у таких типов нет безопасного значения, которое можно подставить автоматически.
Правила выполнения
Один корневой компонент
На одной поверхности GenUI рисует ровно один компонент каталога. Внутри он может быть сколь угодно сложным, но обернуть его в Column, Container или другой виджет, которого нет в каталоге, модель не может.
Только то, что в каталоге
Компонента нет в каталоге — для модели его не существует.
Что стоит учесть
Компоненты под списки
Раз корневой компонент один, для наборов данных удобны компоненты, принимающие List<T>:
TransactionListSearchResultsGridCartItemsSummary
Небольшие компоненты лучше экранов
Хороший компонент каталога — переиспользуемый блок:
ProductCardOrderSummaryInvoicePreviewReviewSummaryAppointmentConfirmation
Компонент размером с целую страницу и переиспользовать сложнее, и модели труднее понять, когда его брать.
Одинаковые DataStruct у инструментов и компонентов
Если инструмент возвращает ProductStruct, компонент каталога должен принимать ProductStruct или List<ProductStruct>. Тогда путь от получения данных к их отображению не требует преобразований.
Описывайте параметры как документацию API
Хорошо:
estimatedDeliveryDate— «ожидаемая дата доставки в формате ISO 8601»;inventoryStatus— «состояние наличия, показываемое пользователю: inStock или backOrdered».
Плохо:
datestatus
Конкретные имена
Хорошо:
OrderStatusCardSensorAlertSummaryQuoteBreakdown
Плохо:
Card1SummaryDetails
Без пересечений
Если два компонента делают примерно одно и то же, модели остаётся угадывать. Объедините их, переименуйте понятнее или сузьте назначение каждого.