Skip to main content

​
Поради зі створення застосунків

​
1. Спочатку визначте дані

Teable App Builder працює на основі наявних Таблиць Teable: ваші Таблиці й Поля є схемою, яку ШІ безпосередньо читає під час створення інтерфейсу та логіки. Тому перед початком роботи чітко визначте модель даних. Що точніше задано типи Полів, зв’язки та шляхи читання й запису, то якіснішим буде результат роботи ШІ.

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

Навіть після підготовки моделі даних не поспішайте одразу створювати інтерфейс. Спочатку виконайте етап планування разом із ШІ. Напишіть щось на кшталт: «Поки що не пиши код — спочатку складімо план». Опишіть проблему, яку потрібно розв’язати, цільових користувачів і приблизний набір функцій. Дозвольте ШІ підготувати структуровану пропозицію. Перегляньте й скоригуйте її та починайте створення лише тоді, коли погодитеся, що план доцільний.
Кілька додаткових хвилин на узгодження напрямку на початку заощадять години на подальше перероблення.

​
3. Починайте з малого

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

​
4. Формулюйте конкретно, а не абстрактно

Описи на кшталт «зроби красивіше» або «зроби взаємодію природнішою» майже не дають ШІ корисної інформації. Ефективні запити конкретні: яка сторінка, яка область, якої поведінки ви очікуєте та чого не хочете. Також дуже допомагають прикріплені знімки екрана або приклади інтерфейсів.
Ставтеся до запиту як до технічного завдання для кмітливої людини, яка нічого не знає про ваш проєкт. Що точніші вказівки, то ближчим буде результат до вашого задуму.

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

Якщо застосунок поводиться неочікувано, не поспішайте просити ШІ «просто виправити це». Нечіткі вказівки щодо виправлення змушують ШІ змінювати код навмання, часто спричиняючи нові помилки. Краще діяти у два етапи:
1

Спочатку попросіть ШІ провести аналіз

Опишіть ознаки проблеми й попросіть ШІ перелічити ймовірні причини та можливі підходи, поки що не змінюючи код.
2

Виберіть напрямок і реалізуйте рішення

Визначте найімовірніше пояснення й доручіть ШІ діяти відповідним чином.
Якщо кілька послідовних спроб виправлення не дали результату, поверніться до останньої гарантовано робочої версії та почніть заново. Зазвичай це швидше, ніж накладати нові виправлення на попередні.

​
6. Використовуйте відновлення версій

Кожна розмова із ШІ призводить до змін. Рекомендований ритм роботи: завершіть один функціональний модуль, переконайтеся, що він працює, і лише потім переходьте далі. Не працюйте одночасно над кількома незавершеними функціями. Пізніша зміна щось зламала? Поверніться до останньої стабільної версії та повторіть спробу з чіткішим запитом.

​
Поширені запитання

​
App Builder підтримує лише Next.js

Середовище виконання App Builder (пісочниця, попередній перегляд і збірка) побудовано на Next.js і наразі не підтримує інші фреймворки для інтерфейсу, зокрема Astro, Vite, Create React App, Vue, Svelte тощо. Якщо попросити ШІ використати інший фреймворк, він може не відмовитися послідовно й навіть спробувати згенерувати відповідний код. Однак через несумісність базового середовища попередній перегляд не запуститься: повідомлення «Запуск попереднього перегляду…» відображатиметься безкінечно, а розмови весь цей час продовжуватимуть витрачати кредити.
Якщо вам потрібно використовувати фреймворк, відмінний від Next.js, рекомендуємо вести розробку у власному локальному середовищі й підключатися до даних через API Teable.

​
Обробка помилок 429

Наразі для API Teable діє обмеження 10 QPS (10 запитів на секунду). Застосунки, створені за допомогою App Builder, можуть отримувати помилки 429 під час звичайної роботи, якщо обробку запитів не оптимізовано. Наша команда розробників активно оптимізує продуктивність API, тому це обмеження може змінитися в майбутньому.
Існують чотири основні стратегії розв’язання цієї проблеми:

Кешування

Зменшення кількості повторних запитів

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

Зменшення обсягу даних у кожному запиті

Затримка та обмеження частоти

Зниження частоти запитів

Сумісність відображення

Зменшення кількості помилок попереднього перегляду
У кожному розділі нижче наведено поширені сценарії, спосіб виправлення та зразок запиту, який можна використовувати повторно. Кешування — зменшення кількості повторних запитів
Сценарій: сторінка інформаційної панелі містить кілька діаграм, карток статистики та списків, кожен із яких запитує дані з іншої Таблиці. Або сторінка призначена переважно для перегляду, але під час кожного відвідування все одно безпосередньо звертається до API. В обох випадках кількість одночасних запитів під час завантаження сторінки може різко зрости, а сплески трафіку з більшою ймовірністю спричинять помилки 429.Виправлення: надавайте перевагу способам відображення, зручним для кешування. Після завантаження кешуйте дані в пам’яті застосунку (для початку підійде TTL у 1–3 хвилини) і повторно використовуйте їх під час наступних відвідувань. Застосовуйте відкладене завантаження до компонентів нижче видимої області, щоб рознести запити в часі. Якщо сторінка й надалі повторно отримує дані під час кожного відвідування, прямо попросіть ШІ посилити стратегію кешування.
Зразок запиту: «Ця сторінка містить багато вмісту для перегляду. Використовуй підхід до відображення, зручний для кешування. Після завантаження сторінки кешуй дані локально з TTL 1 хвилина, не надсилай повторних запитів до API протягом дії TTL і затримай компоненти нижче видимої області на 500 мс».
Сценарій: трьом компонентам на одній сторінці потрібні дані з тієї самої Таблиці, і кожен надсилає власний запит, хоча було б достатньо одного.Виправлення: централізуйте отримання даних, щоб той самий набір завантажувався один раз і спільно використовувався компонентами.
Зразок запиту: «Якщо кільком компонентам потрібні дані з тієї самої Таблиці, отримай їх один раз і надай усім цим компонентам. Не надсилай повторних запитів».
Сценарій: користувачі переходять між сторінками туди й назад. Кожне повернення спричиняє нове отримання даних, навіть якщо нічого не змінилося.Виправлення: протягом дії TTL кешу повторно використовуйте раніше завантажені дані замість нового запиту.
Зразок запиту: «Коли користувач повертається на сторінку, використовуй кешовані дані, якщо з часу останнього завантаження минуло менше хвилини. Не надсилай повторний запит до API».
Сценарій: розкривний список показує кожен Запис із Таблиці як варіант. За великої кількості Записів навіть цей один запит створює значне навантаження.Виправлення: перетворіть його на засіб вибору з пошуком — отримуйте відповідні Записи лише після введення тексту користувачем. Або кешуйте список варіантів.
Зразок запиту: «Розкривні списки не повинні завантажувати всі варіанти заздалегідь. Перейди до пошуку за ключовими словами, який отримує відповідні Записи після введення тексту, із застосуванням затримки».
Сценарій: вибір одного Поля запускає завантаження варіантів наступного рівня. Багаторівневі каскади створюють кілька запитів за кожну взаємодію.Виправлення: один раз попередньо завантажте пов’язані дані й фільтруйте їх локально або кешуйте каскадні дані після першого завантаження.
Зразок запиту: «Після завантаження кешуй локально дані варіантів каскадного селектора. Коли користувач змінює батьківський варіант, фільтруй дані з кешу замість повторного запиту».
Сценарій: неналежне керування станом змушує компоненти повторно отримувати дані під час кожного відображення.Виправлення: запускайте отримання даних за певними подіями (початкове монтування, явна дія користувача), а не під час кожного відображення. Використовуйте кешування як додатковий захист.
Зразок запиту: «Отримуй дані лише під час першого завантаження сторінки або явних дій користувача. Не отримуй дані повторно під час повторного відображення — використовуй кешовані дані».
Пагінація та пакетна обробка — зменшення обсягу даних у кожному запиті
Сценарій: завантаження всіх Записів одночасно спричиняє шквал викликів API зі зростанням набору даних.Виправлення: використовуйте пагінацію. Отримуйте дані лише для поточної сторінки.
Зразок запиту: «Показуй по 20 рядків на сторінці. Завантажуй наступну сторінку, лише коли користувач переходить до неї. Не завантажуй усе одночасно».
Сценарій: після завантаження списку ви по одному отримуєте відомості з пов’язаної Таблиці для кожного Запису. Завантаження 50 проєктів, а потім 50 відомостей про власників означає 50 додаткових запитів за одну мить.Виправлення: отримуйте всі пов’язані дані одним пакетом, а не рядок за рядком.
Зразок запиту: «Під час завантаження списку отримуй усі пов’язані дані одним пакетним запитом. Не перебирай Записи, щоб окремо отримувати пов’язані з ними відомості».
Сценарій: під час масового оновлення кількох Записів для кожного з них надсилається окремий запит замість одного пакетного.Виправлення: скористайтеся API пакетного оновлення, щоб надіслати всі зміни одним викликом.
Зразок запиту: «Для масових операцій об’єднуй зміни кількох Записів в один пакетний запит. Не надсилай окремий запит оновлення для кожного Запису».
Сценарій: цикл for опрацьовує Записи по одному, викликаючи API на кожній ітерації.Виправлення: спочатку зберіть усі ідентифікатори, а потім надішліть один пакетний запит.
Зразок запиту: «Не викликай API всередині циклу. Спочатку збери всі потрібні ідентифікатори, а потім надішли один пакетний запит».
Затримка та обмеження частоти — зниження частоти запитів
Сценарій: кожне натискання клавіші в полі пошуку надсилає запит. Введення запиту з 4 символів створює 4 запити.Виправлення: додайте затримку введення — після того як користувач припинить вводити текст, зачекайте 300–500 мс перед надсиланням запиту.
Зразок запиту: «Додай затримку до введення пошукового запиту. Надсилай запит лише через 300 мс після того, як користувач припинив вводити текст. Не надсилай запити під час введення».
Сценарій: швидкі повторні натискання кнопки надсилання, перемикання фільтрів або перегортання сторінок — кожна дія негайно надсилає запит.Виправлення: застосуйте затримку або обмеження частоти. Вимикайте кнопки надсилання до завершення запиту, щоб запобігти повторному надсиланню.
Зразок запиту: «Вимкни кнопку надсилання після натискання й увімкни знову після завершення запиту. Додай затримку до зміни фільтрів, щоб швидкі зміни протягом 300 мс надсилали лише один запит».
Сценарій: кожна зміна Поля негайно зберігається. Заповнення форми може спричинити десятки операцій запису.Виправлення: перейдіть до явного збереження після натискання кнопки або додайте затримку автозбереження, щоб воно виконувалося один раз після паузи в редагуванні.
Зразок запиту: «Не зберігай дані після кожної зміни Поля. Зберігай їх після явного натискання кнопки або автоматично один раз, коли користувач призупинив редагування на 2 секунди».
Сценарій: дані оновлюються кожні кілька секунд, постійно створюючи високочастотний трафік.Виправлення: збільште інтервал опитування до обґрунтованого значення (30 секунд або більше) чи перейдіть до оновлення вручну.
Зразок запиту: «Установи інтервал автоматичного оновлення 60 секунд. Додай кнопку ручного оновлення, щоб користувачі могли отримувати найновіші дані за потреби».
Сценарій: кілька компонентів на сторінці налаштовують власні таймери опитування. Сукупне навантаження легко перевищує обмеження.Виправлення: централізуйте опитування. Виконуйте одне періодичне отримання даних, а потім розподіляйте результат між усіма компонентами, яким він потрібен.
Зразок запиту: «Не дозволяй кожному компоненту налаштовувати власний таймер опитування. Використовуй єдиний механізм оновлення, який отримує всі дані за розкладом і розподіляє їх між компонентами».
Сумісність відображення — зменшення кількості помилок попереднього перегляду
Сценарій: сторінка використовує діаграми, карти або бібліотеки, що залежать від window, вимірювань DOM чи інших API, доступних лише в браузері, а в попередньому Перегляді з’являються помилки, порожній екран або невідповідності гідратації.Виправлення: такі компоненти часто безпечніше завантажувати в браузері, а не відображати безпосередньо на сервері. Якщо проблеми з попереднім переглядом не зникають, прямо попросіть ШІ перейти на шаблон завантаження лише в браузері.
Зразок запиту: «Цей компонент залежить від середовища браузера. Завантажуй його лише на клієнті, щоб уникнути помилок відображення в попередньому перегляді або невідповідностей гідратації».
ШІ може помилятися. Обов’язково перевіряйте відповіді.
Останнє оновлення 4 вересня 2026 р.