Skip to main content

​
Советы по созданию

​
1. Сначала определите данные

Конструктор приложений Teable работает поверх существующих таблиц Teable — ваши таблицы и поля являются вашей схемой, и ИИ считывает их напрямую при создании интерфейса и логики. Поэтому перед началом разработки чётко определите модель данных. Чем точнее типы полей, связи и пути чтения/записи, тем выше качество результата, который создаёт ИИ.

​
2. Планируйте перед созданием

Даже когда модель данных уже готова, не спешите сразу переходить к созданию интерфейса. Сначала выполните с ИИ этап планирования. Скажите что-нибудь вроде: «Давайте пока не будем писать код — давайте составим план». Опишите решаемую проблему, целевых пользователей и примерный набор функций. Позвольте ИИ подготовить структурированное предложение. Просмотрите его, скорректируйте и начинайте разработку только после того, как убедитесь в осмысленности плана.
Несколько дополнительных минут, потраченных на согласование направления в начале, сэкономят часы переделок позже.

​
3. Начинайте с малого

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

​
4. Будьте конкретны, а не абстрактны

Такие описания, как «сделайте красивее» или «сделайте взаимодействия более естественными», почти не дают ИИ никакой информации. Эффективные запросы конкретны: какая страница, какая область, какое поведение вам нужно, чего вы не хотите. Также очень помогают прикреплённые снимки экрана или интерфейсы-образцы.
Относитесь к своему запросу как к брифу для умного человека, который ничего не знает о вашем проекте. Чем точнее инструкции, тем ближе результат к тому, что вы представляли.

​
5. Диагностируйте перед исправлением

Когда приложение ведёт себя неожиданно, не поддавайтесь желанию сказать ИИ: «просто исправь это». Расплывчатые инструкции по исправлению подталкивают ИИ к слепому внесению правок, часто попутно создавая новые ошибки. Лучший подход состоит из двух шагов:
1

Сначала попросите ИИ проанализировать

Опишите симптомы и попросите ИИ перечислить вероятные причины и возможные подходы — пока не изменяя код.
2

Выберите направление, затем реализуйте

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

​
6. Используйте откаты версий

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

​
Часто задаваемые вопросы

​
Конструктор приложений поддерживает только Next.js

Среда выполнения Конструктора приложений (песочница, предварительный просмотр и сборка) построена на Next.js и сейчас не поддерживает другие фронтенд-фреймворки, включая Astro, Vite, Create React App, Vue, Svelte и т. д. Если попросить ИИ использовать фреймворк, отличный от Next.js, он может не всегда последовательно отказываться и даже попытаться сгенерировать соответствующий код. Однако из-за несовместимости базовой среды предварительный просмотр не запустится — вы будете бесконечно видеть «Предварительный просмотр запускается…», а разговоры продолжат расходовать кредиты в это время.
Если вам нужен фреймворк, отличный от Next.js, рекомендуем разрабатывать в собственной локальной среде и подключаться к данным через API Teable.

​
Обработка ошибок 429

Teable API сейчас ограничен 10 QPS (10 запросами в секунду). Приложения, созданные Конструктором приложений, могут сталкиваться с ошибками 429 при обычном использовании, если обработка запросов не оптимизирована. Наша инженерная команда активно работает над оптимизацией производительности API, и в будущем мы можем скорректировать это ограничение.
Существует четыре основных стратегии для решения этой проблемы:

Кэширование

Сокращайте число повторяющихся запросов

Пагинация и пакетная обработка

Уменьшайте объём данных в каждом запросе

Debounce и throttle

Снижайте частоту запросов

Совместимость рендеринга

Сокращайте ошибки предварительного просмотра
В каждом разделе ниже перечислены распространённые сценарии, решение и пример запроса, который можно использовать повторно. Кэширование — сокращение повторяющихся запросов
Сценарий: На странице панели мониторинга есть несколько диаграмм, карточек статистики и списков, каждый из которых запрашивает другую таблицу. Или страница предназначена преимущественно для отображения, но при каждом посещении всё равно напрямую обращается к API. В обоих случаях параллелизм при загрузке страницы может резко возрасти, а всплески трафика с большей вероятностью вызовут ошибки 429.Решение: Отдавайте предпочтение шаблонам рендеринга, удобным для кэширования. После загрузки кэшируйте данные в памяти приложения (хорошая отправная точка — TTL 1–3 минуты) и повторно используйте их при последующих посещениях. Лениво загружайте компоненты ниже сгиба, чтобы распределить запросы во времени. Если страница всё ещё повторно получает данные при каждом посещении, явно попросите ИИ усилить стратегию кэширования.
Пример запроса: “Это страница с большим объёмом отображаемых данных. Используйте подход к рендерингу, удобный для кэширования. После загрузки страницы кэшируйте данные локально с TTL 1 минуту, не запрашивайте API повторно в пределах окна TTL и отложите компоненты ниже сгиба на 500 мс.”
Сценарий: Трём компонентам на одной странице нужны данные из одной таблицы, и каждый отправляет собственный запрос, хотя хватило бы одного.Решение: Централизуйте получение данных, чтобы один и тот же набор данных загружался один раз и использовался всеми компонентами.
Пример запроса: “Если нескольким компонентам нужны данные из одной таблицы, получите их один раз и предоставьте всем компонентам. Не отправляйте дублирующие запросы.”
Сценарий: Пользователи переходят между страницами туда и обратно. При каждом возвращении происходит новое получение данных, даже когда ничего не изменилось.Решение: В пределах TTL кэша используйте ранее загруженные данные вместо повторного запроса.
Пример запроса: “Когда пользователь возвращается на страницу, если с последней загрузки прошло меньше 1 минуты, используйте кэшированные данные. Не запрашивайте API повторно.”
Сценарий: Выпадающий список показывает в качестве вариантов каждую запись из таблицы. При большом количестве записей уже один такой запрос становится тяжёлым.Решение: Преобразуйте его в средство выбора с поиском — получайте только совпадающие записи после ввода пользователем текста. Либо кэшируйте список вариантов.
Пример запроса: “Выпадающие списки не должны загружать все варианты заранее. Переключитесь на поиск по ключевым словам, который получает совпадающие записи при вводе, с применением debounce.”
Сценарий: Выбор одного поля вызывает загрузку вариантов следующего уровня. Многоуровневые каскады накапливают несколько запросов за одно взаимодействие.Решение: Один раз предварительно загрузите связанные данные и фильтруйте их локально либо кэшируйте данные каскада после первой загрузки.
Пример запроса: “После загрузки кэшируйте данные вариантов каскадного селектора локально. Когда пользователь меняет родительский вариант, фильтруйте данные из кэша вместо повторного запроса.”
Сценарий: Плохое управление состоянием заставляет компоненты повторно получать данные при каждом рендеринге.Решение: Запускайте получение данных по конкретным событиям (первое монтирование, явное действие пользователя), а не при каждом рендеринге. Используйте кэширование как страховку.
Пример запроса: “Получайте данные только при первой загрузке страницы или явных действиях пользователя. Не получайте данные повторно при повторном рендеринге — вместо этого используйте кэшированные данные.”
Пагинация и пакетная обработка — уменьшение объёма данных в каждом запросе
Сценарий: Загрузка всех записей сразу создаёт поток вызовов API по мере роста набора данных.Решение: Используйте пагинацию. Получайте только данные текущей страницы.
Пример запроса: “Показывайте 20 строк на странице. Загружайте следующую страницу только когда пользователь переходит на неё. Не загружайте всё сразу.”
Сценарий: После загрузки списка вы по очереди получаете сведения из связанной таблицы для каждой записи. Загрузка 50 проектов, а затем 50 запросов владельцев = 50 дополнительных запросов мгновенно.Решение: Получайте все связанные данные одним пакетом, а не построчно.
Пример запроса: “При загрузке списка пакетно получите все связанные данные одним запросом. Не перебирайте записи, чтобы получать их связанную информацию по отдельности.”
Сценарий: Массовое обновление нескольких записей путём отправки одного запроса на обновление для каждой записи вместо одного пакетного запроса.Решение: Используйте API пакетного обновления, чтобы отправить все изменения одним вызовом.
Пример запроса: “Для массовых операций объединяйте изменения нескольких записей в один пакетный запрос. Не отправляйте одно обновление для каждой записи.”
Сценарий: Цикл for обрабатывает записи по одной, вызывая API на каждой итерации.Решение: Сначала соберите все ID, затем выполните один пакетный запрос.
Пример запроса: “Не вызывайте API внутри цикла. Сначала соберите все необходимые ID, затем выполните один пакетный запрос.”
Debounce и throttle — снижение частоты запросов
Сценарий: Каждое нажатие клавиши в поле поиска отправляет запрос. Ввод запроса из 4 символов создаёт 4 запроса.Решение: Примените debounce к вводу — подождите 300–500 мс после того, как пользователь перестал печатать, прежде чем отправлять запрос.
Пример запроса: “Примените debounce к полю поиска. Отправляйте запрос только через 300 мс после того, как пользователь перестал печатать. Не отправляйте запросы во время ввода.”
Сценарий: Быстрые повторные нажатия «Отправить», быстрое переключение фильтров, быстрая пагинация — каждое действие немедленно отправляет запрос.Решение: Примените debounce или throttle. Отключайте кнопки отправки до завершения запроса, чтобы предотвратить двойную отправку.
Пример запроса: “Отключайте кнопку отправки после нажатия и включайте её снова после выполнения запроса. Примените debounce к изменениям фильтра, чтобы быстрые изменения в пределах 300 мс отправляли только один запрос.”
Сценарий: Каждое изменение поля сохраняется немедленно. Заполнение формы может вызвать десяток операций записи.Решение: Переключитесь на явное сохранение по нажатию кнопки или примените debounce к автосохранению, чтобы оно срабатывало один раз после паузы в редактировании.
Пример запроса: “Не сохраняйте при каждом изменении поля. Сохраняйте по явному нажатию кнопки или выполняйте автосохранение один раз после того, как пользователь приостановил редактирование на 2 секунды.”
Сценарий: Данные обновляются каждые несколько секунд, создавая постоянный высокочастотный трафик.Решение: Увеличьте интервал опроса до разумного значения (30 секунд или больше) либо переключитесь на ручное обновление.
Пример запроса: “Установите интервал автообновления 60 секунд. Добавьте кнопку ручного обновления, чтобы пользователи могли получать последние данные по запросу.”
Сценарий: Несколько компонентов на странице каждый настраивает собственный таймер опроса. Совокупная нагрузка легко превышает лимит.Решение: Централизуйте опрос. Выполняйте одно периодическое получение данных, затем передавайте результат каждому нуждающемуся компоненту.
Пример запроса: “Не позволяйте каждому компоненту настраивать собственный таймер опроса. Используйте единый механизм обновления, который получает всё по расписанию и распределяет данные между компонентами.”
Совместимость рендеринга — сокращение ошибок предварительного просмотра
Сценарий: Страница использует диаграммы, карты или библиотеки, зависящие от window, измерений DOM либо других API, доступных только в браузере, и в предварительном просмотре появляются ошибки, пустой экран или несоответствия гидратации.Решение: Такие компоненты часто безопаснее загружать в браузере, а не рендерить непосредственно на сервере. Если проблемы с предварительным просмотром сохраняются, явно попросите ИИ переключить их на шаблон загрузки только в браузере.
Пример запроса: “Этот компонент зависит от среды браузера. Загружайте его только на клиенте, чтобы избежать ошибок рендеринга в предварительном просмотре или несоответствий гидратации.”
ИИ может ошибаться. Пожалуйста, перепроверяйте ответы.
Последнее изменение 4 сентября 2026 г.