Развитие модели и собственная разработка идут параллельно. Не нужно закончить генерацию навсегда, чтобы начать писать бизнес-логику: следующий Generate обновляет свои файлы и сохраняет ваши custom-зоны.
Пример: собственная логика заказа
Пусть в проекте есть сущность Order. Через Content добавьте поля, связи, доступ и стандартное поведение списка. Если нужен расчёт стоимости по правилам компании, пишите его в backend/internal/custom/order/. Для особого интерфейса используйте admin/src/features/order/custom/.
Здесь Order/order — конкретный пример. В остальных руководствах placeholder ENTITY_NAME означает соответствующий каталог вашей сущности, а EntityName — её тип в коде.
- Откройте текущий проект в Generator UI. Настройте модель и сохраните её.
- Параллельно измените свой Go/React-код в custom-файлах. В UI генератора произвольный исходный код не редактируется.
- В Generate → Preview changes просмотрите будущие изменения. Убедитесь, что стандартные файлы обновляются, а существующие custom-файлы сохраняются.
- Выполните Generate. Если менялась схема, просмотрите новые SQL-миграции и примените их локально через
make migrate. - Соберите затронутую часть приложения и проверьте свой пользовательский сценарий. Затем закоммитьте модель, generated-файлы, custom-код и зарегистрированные миграции вместе.
- Выпустите релиз по инструкции обновления. Данные сервера не заменяются локальными записями при обычном deploy.
Что проверять после изменения модели
| Изменение | Что сделать в custom-коде |
|---|---|
| Новое поле | Не потерять его при преобразовании полного объекта и сохранении |
| Localized или nullable | Учесть *string/nil в Go и null в API |
| Переименование или удаление | Обновить обращения к старым полям и контрактам |
| Права доступа | Проверить собственные actions и серверные handlers |
| Новая версия генератора | Сверить контракт hooks, customcontracts и frontend-расширений |
Сохранение custom-файла не гарантирует совместимость его кода с новой моделью. Ошибка компиляции после изменения контракта решается адаптацией собственной реализации, а не правкой generated bootstrap.
Если возник конфликт
Сначала сохраните работу в Git и просмотрите diff. Если вручную изменён generator-owned файл, перенесите требуемую логику в подходящую точку расширения. Не используйте Force как способ скрыть неразобранный конфликт: сначала поймите, какой файл и почему изменится.
Если нужна точка расширения, которой ещё нет, опишите необходимый контракт отдельно. Наличие папки custom не превращает любую ручную правку в поддерживаемое расширение.
Начните с карты custom-зон, затем выберите backend, admin, SQL-миграции или deployment.