Форма в Lovable не сохраняет данные? Промпты для исправления

Если форма в Lovable не сохраняет данные, сначала проверьте, срабатывает ли отправка, принимает ли база данных запись и считывает ли приложение сохраненную строку обратно. Предоставьте эти факты Lovable перед запросом на исправление: зеленая плашка об успехе ничего не доказывает. Здесь собраны готовые промпты, таблица диагностики и чек-лист регрессионного тестирования, чтобы починить сбойный уровень без пересборки формы с нуля.

Примеры для базы данных ниже рассчитаны на Supabase. Если у вас другой бэкенд, сохраняйте тот же алгоритм, но подставляйте запросы, права доступа и логи вашего сервиса. Цель - подтвержденное сохранение, а не конкретная интеграция.

Найдите, где ломается сохранение

Сохранение проходит через несколько уровней: валидация в браузере, обработчик отправки (submit handler), сборка запроса, аутентификация, права доступа в базе данных и запрос, который обновляет экран. Сбой на любом этапе может выглядеть одинаково: как неработающая кнопка.

Начните с одного воспроизводимого сценария. Используйте тестовый аккаунт и уникальное значение, например `SAVE-TEST-1028-A`. Не используйте реальные данные клиентов. Зафиксируйте URL страницы, статус авторизации (вошли ли вы в систему) и то, где именно воспроизводится ошибка: в preview, в опубликованном приложении или везде.

Прежде чем что-то менять, зафиксируйте рабочую версию кода через историю версий или Git в вашем проекте. Если предлагаемое исправление меняет базу данных, отдельно продумайте откат этих изменений. Восстановление фронтенд-кода не возвращает состояние таблиц или политики базы данных.

Потратьте 5-10 минут на сбор фактов, прежде чем просить изменить код.

1. Откройте инструменты разработчика в браузере и перейдите во вкладку Network.
2. Очистите список запросов и отправьте форму один раз.
3. Найдите нужный запрос fetch или XHR. Некоторые приложения вызывают бэкенд-функцию, а не обращаются к базе напрямую.
4. Проверьте статус запроса и очищенное от приватных данных тело ответа (response body).
5. Проверьте вкладку Console на наличие ошибок валидации или JavaScript.
6. В нужном проекте базы данных и таблице найдите тестовое значение-маркер.

Не вставляйте полный экспорт сетевых логов в чат. В нем могут быть токены сессий, cookies или персональные данные. Вместо этого передайте метод, очищенный путь к эндпоинту, статус, текст ошибки и названия полей в payload.

| Что вы видите | Вероятный сбойный уровень | Что проверить дальше | |---|---|---| | Запрос на запись не отправляется | Валидация, обработчик событий или предшествующая ошибка JavaScript | Ошибки полей, Console и submit handler | | Запрос возвращает 401 или 403 | Аутентификация или авторизация | Тело ответа, состояние сессии и действующие политики доступа | | В ответе указано отсутствие колонки или нарушение ограничения (constraint) | Несоответствие payload и схемы | Сравните отправленные поля с реальной структурой таблицы | | Запрос прошел успешно, строка создана, но список не обновился | Запрос на чтение, фильтрация или обновление кэша | Запрос, используемый на целевом экране | | После одного действия появляется две строки | Дублирование отправки или логика повторов (retry) | Количество запросов и привязку обработчика | | В preview все работает, а в продакшене падает | Окружение, деплой или специфика origin | Сравните эндпоинты бэкенда и очищенные ответы |

Это лишь отправные точки, а не окончательный вердикт. Одни только HTTP-статусы редко объясняют всю картину. Проблема авторизации в Supabase может возвращаться с внутренним кодом ошибки базы данных прямо в ответе, поэтому обязательно сохраняйте это сообщение.

Пустой ответ тоже не означает сбой операции insert. Некоторые операции записи не возвращают добавленные строки, если это не запрошено явно. Проверьте базу данных перед тем, как просить Lovable переписывать логику сохранения.

Запрашивайте диагностику перед патчем

Самый дорогой промпт обычно самый короткий: "Форма не работает. Почини."

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

Сначала отправьте запрос исключительно на диагностику. Это ограничение в промпте, а не гарантия того, что анализ бесплатен или что какой-то режим Lovable полностью блокирует правки. Изучите ответ и все предложенные изменения.

```text Проведи диагностику ошибки сохранения формы. Пока не редактируй файлы, не запускай миграции и не меняй конфигурацию.

Страница и форма: [route и название формы] Ожидаемое поведение: [одно предложение] Фактическое поведение: [одно предложение] Окружение: [preview / published / оба] Статус аккаунта: [авторизован / не авторизован; без паролей и токенов] Шаги воспроизведения: [нумерованный список] Очищенные данные: [статус запроса, ошибка в ответе, ошибка в консоли и наличие тестовой строки в базе]

Отследи путь от submit handler до записи в бэкенд, а затем от успешной записи до отображения результата на экране.

Выведи:

1. Сбойный уровень и подтверждающие факты.
2. Затронутые файлы, функции и объекты бэкенда.
3. Минимально необходимое точечное исправление.
4. Что осталось неизвестным и какую точную проверку нужно провести.
5. Приемочные тесты для предложенного фикса.

Отделяй факты от гипотез. Если не можешь проверить бэкенд напрямую, так и скажи. Не придумывай его схему. Не предлагай отключать RLS, раскрывать секреты, менять интеграцию или переписывать форму с нуля. ```

Полезная диагностика указывает точный путь выполнения: submit handler отправляет поле, которого нет в таблице, или insert проходит успешно, но запрос списка данных не обновляется. Ответ в духе "Возможно, есть проблема с Supabase" не несет никакой практической пользы.

Если ассистенту не хватает данных, проведите нужную проверку до того, как одобрять патч. Одно точное наблюдение в браузере может предотвратить три бесполезные попытки наугад переписать код.

Другие шаблоны инструкций можно найти в нашей библиотеке промптов. Здесь же формулируйте задачу узко: одна форма, одна воспроизводимая ошибка, один критерий приемки.

Используйте промпт под ваш тип ошибки

Выберите сценарий, соответствующий собранным данным. Не нужно копировать все шаблоны в один запрос. Если одновременно требовать исправить валидацию на фронтенде, права в базе данных, работу кэша и внешний вид, вы только раздуете скоуп задачи.

Браузер не отправляет запрос

Встроенная валидация браузера может заблокировать отправку еще до вызова обработчика. Кроме того, у кнопки может быть указан неверный type, либо исключение падает до вызова функции записи.

Запрашивайте исправление пути отправки, а не переделку бэкенда:

```text Форма на странице [route] не генерирует запрос на запись. Факты: [очищенная ошибка из консоли или поведение валидации].

Проверь нативную валидацию браузера, валидацию библиотеки форм, тип кнопки (button type), привязку событий и ошибки перед вызовом бэкенда. Найди реальную причину блокировки.

Исправь только подтвержденный дефект на пути отправки формы. Сохрани существующие правила полей и верстку. Не меняй базу данных, auth, зависимости или другие формы.

Сделай ошибки валидации видимыми для пользователя. Убедись, что одна корректная отправка инициирует ровно один запрос на запись. Перечисли измененные файлы и четко отдели запущенные тесты от тех, которые предлагается провести вручную. ```

Не удаляйте валидацию только ради того, чтобы кнопка ожила. Если необязательное поле ошибочно помечено как required, исправьте само правило. Если обязательное поле скрыто, исправьте логику его отображения или видимость.

База данных отклоняет запись

Для этого сценария нужны текст ошибки и схема данных. Отсутствие обязательного значения, невалидный enum, нарушение внешнего ключа (foreign-key) и блокировка со стороны Row Level Security требуют совершенно разных решений.

В Supabase за доступ к строкам отвечает механизм Row-Level Security, или RLS. Для авторизованной вставки может потребоваться поле привязки к текущему пользователю и соответствующая политика (insert policy). Заполнение поля владельца на стороне браузера само по себе не защищает данные - проверку авторизации обязана обеспечивать база.

```text Бэкенд отклоняет запись из формы. Таблица или функция: [название] Очищенный текст ошибки: [точный код и сообщение] Поля в payload: [только названия полей] Известная схема и политики: [проверенные детали или "неизвестно"] Требуемый доступ: [кто и какие записи имеет право создавать]

Сравни payload, ограничения схемы (constraints), статус аутентификации и соответствующие политики доступа. Исправь только подтвержденное несоответствие. Не додумывай детали схемы.

Сохрани RLS и принцип наименьших привилегий. Никогда не помещай service-role key или другие серверные секреты во фронтенд-код. Не открывай публичный доступ на запись в качестве обходного пути.

Если требуется изменить базу данных, предложи эти изменения отдельно: опиши последствия для безопасности, подготовь запросы для проверки и ограничения отката. Не применяй изменения без подтверждения. В остальных случаях сделай минимальный точечный патч в коде. ```

Форма сбора лидов для анонимных пользователей требует иной модели доступа, чем форма в личном кабинете. Сформулируйте это требование явно. Для публичных форм также необходима защита от спама и злоупотреблений: вариант "записывать может кто угодно" не подходит для продакшена.

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

Строка создана, но в приложении ничего не меняется

Прекратите отладку операции вставки. У вас есть доказательство, что она сработала.

Запрос на чтение может отфильтровывать новую запись, текущая страница может быть отсортирована иначе, либо устарели закэшированные данные. Кроме того, права на чтение могут запрещать пользователю загружать ту самую строку, которую ему только что разрешили добавить.

```text Запись проходит успешно, тестовая строка существует в таблице [таблица]. Интерфейс на [route] ее не отображает. Факты: [маркер тестовой записи, активные фильтры, очищенный ответ сервера].

Не трогай рабочий путь вставки данных и схему базы. Изучи запрос на чтение, права доступа, фильтры, сортировку, пагинацию и инвалидацию кэша на этом экране. Определи точную причину до применения патча.

Используй существующий в проекте паттерн выборки данных (data-fetching). Не подключай новые библиотеки управления состоянием и не используй полную перезагрузку страницы в качестве фикса. Покажи корректное состояние после сохранения, не ломая фильтры и правила доступа.

Проверь видимость записи после сохранения, после перехода по страницам и после жесткой перезагрузки (hard refresh). ```

Если новая запись логично не попадает под активный фильтр, правильным решением может стать понятное уведомление: "Сохранено. Запись не отображается из-за текущих фильтров". Принудительный вывод записи в список лишь породит новый баг.

Проверьте исправление и ограничьте расход кредитов

Заложите бюджет отдельно на диагностику, исправление и проверку. Оценка ниже - это ориентир для планирования простой воспроизводимой ошибки в одной форме, а не строгий норматив или гарантия результата.

| Этап | Запас времени | Запланировано запросов к AI | |---|---|---| | Воспроизведение и сбор данных | 5-10 минут | 0 | | Диагностика сбойного уровня | 5-10 минут | 1 | | Применение точечного патча | 10-20 минут | 1 | | Тестирование и ревью диффа | 10-15 минут | 1 | | Корректировка на основе фактов (при необходимости) | 5-10 минут | 0-1 |

В сумме это около 30-55 минут без учета возможной доработки и три запланированных запроса к AI. Один запрос - это не фиксированное число кредитов. Реальный расход зависит от текущих тарифов Lovable и объема выполненных операций.

По состоянию на 28 октября 2026 года опирайтесь на статистику использования в личном кабинете, чтобы отслеживать траты, а не воспринимайте пример как гарантию экономии кредитов. Основные принципы списания описаны в нашем руководстве по ценам Lovable.

Прямые дополнительные расходы могут составить $0, если работа укладывается в доступные кредиты и бесплатные лимиты бэкенда. Но это не делает исправление бесплатным: оно все равно расходует время и баланс. Перед началом задайте лимит, например не более $5 на покупку дополнительных кредитов без пересмотра диагноза. Это финансовое ограничение, а не фиксированная стоимость ремонта.

После двух неудачных попыток перестаньте отправлять очередные вариации фразы "почини это". Воспроизведите баг заново и соберите новые данные. Если патч привел к регрессии, вернитесь к заведомо рабочей версии кода и только потом продолжайте, не забывая отдельно проверить состояние базы данных.

Чек-лист для проверки:

• [ ] Одна корректная отправка создает ровно одну ожидаемую запись.
• [ ] Ошибки обязательных полей видны пользователю и блокируют отправку некорректных данных.
• [ ] При отклонении записи выводится ошибка, а не сообщение об успехе.
• [ ] Отправка по клавише Enter и быстрый двойной клик не создают дубликатов.
• [ ] Индикаторы загрузки корректно возвращаются в исходное состояние и при успехе, и при ошибке.
• [ ] Запись остается сохраненной после жесткой перезагрузки страницы (hard refresh).
• [ ] Настроенные фильтры и права на чтение по-прежнему работают.
• [ ] Второй тестовый аккаунт не имеет доступа к приватным записям первого пользователя.
• [ ] Preview и опубликованное приложение ведут себя одинаково корректно.
• [ ] В diff отсутствуют случайные изменения логики авторизации, оплаты или верстки.

Блокировка кнопки отправки помогает избежать случайных дублей, но для критически важных операций также требуется идемпотентность на стороне сервера или constraints в базе данных. Не принимайте интерфейсные ограничения за стопроцентную гарантию.

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

Почему форма в Lovable пишет об успехе, но не сохраняет данные?

Сообщение об успехе может срабатывать до завершения записи, либо код игнорирует возвращаемую ошибку. Проверьте запрос в сети и запись в базе данных. Показывайте статус успешного сохранения только после того, как бэкенд подтвердит выполнение операции.

Стоит ли отключать Supabase RLS для починки формы?

Нет, для продакшена это неприемлемо. Проверьте статус аутентификации, payload и действующие политики. Устраните конкретное несоответствие в правах доступа, сохранив запланированные границы безопасности, и протестируйте результат под разными аккаунтами.

Сколько кредитов Lovable уходит на починку формы?

Точной фиксированной цифры нет. Разделите работу на диагностику, точечный патч и верификацию, а затем отслеживайте реальный расход в аккаунте. Промпты с опорой на факты избавляют от лишних догадок, но не дают жестких гарантий экономии кредитов.