Англійська для розробників TanStack Query

TanStack Query (раніше React Query) став стандартним способом керування станом сервера в React-застосунках, керування кешуванням, фоновим отриманням і синхронізацією. Якщо ви працюєте з TanStack Query у міжнародній команді, вам знадобиться чітка англійська мова для опису поведінки кешування, анульування і потоків мутацій. Цей посібник містить основні словники для розробників TanStack Query.

Ключовий словник

** Запит ** — декларативний запит на асинхронні дані, визначений унікальним ключем, який TanStack Query кешує і керує ним автоматично. “Ми визначили запит для профілю користувача, ключ ['user', userId], тому він кешується і спільно використовується всіма компонентами, які його потребують.”

** Ключ запиту ** — унікальний ідентифікатор, який використовується для кешування, отримання і скасування даних певного запиту.

• “Ми включаємо параметри фільтра у ключ запиту, отже зміна фільтра автоматично запускає новий запит, який кешується окремо.” *

** Мутація ** — операція, яка створює, оновлює або вилучає дані на сервері, на відміну від запиту, який лише читає дані.

• “Ми використовуємо мутацію для надсилання форми, і при успішному завершенні ми анульовуємо пов’ язаний запит, щоб інтерфейс користувача відображав нові дані.” *

** Час затримки ** — час, протягом якого кешовані дані вважатимуться свіжими і не буде викликано повторного отримання у фоновому режимі. “Ми встановили п’ятихвилинний час затримки запиту на ціни, оскільки ціни рідко змінюються і нам не потрібно переодержувати їх при кожному відтворенні.”

** Час кешування (gcTime) ** — час, протягом якого не використані дані запиту залишаються у пам’ яті до їх збирання. “Ми збільшили час кешування результатів пошуку, тому повернення до попереднього пошуку не потребує повного повторного отримання.”

** Invalidation ** — явне позначення кешованих даних запиту як застарілих, примусове отримання даних знову, коли вони будуть потрібні. “Після успішної мутації, ми анульовуємо запит todos, щоб список було оновлено за допомогою новоствореного елемента.”

** Оптимістичне оновлення ** — оновлення локального кешу негайно, перед тим, як сервер підтвердить зміну, щоб інтерфейс користувача виглядав як миттєвий.

• “Ми використовуємо оптимістичні оновлення, коли користувачеві подобається повідомлення, тому кількість подобається змінюється миттєво, замість очікування на подорож мережі в обидва боки.” *

** Background refetch ** — запит TanStack автоматично переодержує дані поза сценою, наприклад, коли вікно знову отримує фокус.

• « Перезавантаження у тлі при фокусуванні вікна зберігає точність панелі інструментів, якщо користувач перемикає вкладки і повертається пізніше. » *

** Каскад скасування запиту ** — шаблон скасування декількох пов’ язаних запитів після однієї мутації, щоб зберегти послідовність всіх залежних переглядів.

• “Вилучення проекту викликає каскад, який скасовує чинність списку проектів, резюме панелі інструментів і подачі останніх дій.” *

Обговорення стратегії кешування

• «Ми встановлюємо більш тривалий час застаріння на посилання даних, таких як списки країн, оскільки вони змінюються так рідко»
• «Ключ запиту включає номер сторінки сторінкування, тому кожна сторінка кешується незалежно і перемикання сторінок відчувається миттєво.»
• «Ми вимикаємо фонове завантаження на цьому конкретному запиту, тому що це спричинило зсув макету для користувачів»

Розмовляти про мутації і послідовність

• «Ми повертаємо оптимістичне оновлення, якщо мутація зазнає невдачі, тому інтерфейс ніколи не показує постійну брехню про стан сервера»
• «Недійсним значення точного ключа запиту, а не всього кешу, утримує не пов’язані частини інтерфейсу користувача від небажаного перезавантаження.»
• «Ми використовуємо onSettled для анульування незалежно від успіху або невдачі, оскільки будь-який результат може означати зміну стану сервера»

Професійні поради

1. ** Виберіть час застарівання навмисно, а не типово. ** Поясніть переглядачам, чому запит є свіжим протягом п’ яти хвилин, а не отримується знову при кожному монтуванні.
2. ** Визначте обсяг перевірки. ** Занадто широка перевірка спричиняє непотрібний мережевий трафік; занадто вузька перевірка залишає застарілі дані на екрані.
3. ** Завжди обробляти шлях відновлення для оптимістичних оновлень. ** Неуспішна мутація без логіки відновлення залишає інтерфейс користувача з неправильними даними.

Практичні вправи

1. Поясніть співробітнику команди 3- 4 реченнями різницю між часом застаріння і часом кешування.
2. Напишіть коротке пояснення (4- 5 речень), чому ви використовували оптимістичні оновлення для кнопки « Люблю », але не для повідомлення про сплату.
3. Опишемо простою англійською мовою ваду, спричинену недійсністю надто широкого запиту, і те, як ви зменшили ключ запиту, щоб виправити її.

Національний гідрографічний інститут: Відповідь і відповіді

Для не-рідних носіїв, тонкощі професійної англійської мови можуть відчувати себе особливо викликом. Це не просто про те, щоб знати * слова * для “запит” або “мутація”, але розуміння того, як ці слова використовуються в рамках спільного потоку роботи, особливо при обговоренні технічної зворотного зв’язку. Розглянемо звичайний сценарій: ви надіслали запит на витягування (PR), що містить оптимістичну реалізацію оновлення за допомогою гачка TanStack Query useMutation. Під час перегляду коду ваш колега залишає коментар: « Це виглядає добре в ізоляції, але я хвилююся щодо можливих умов перегонів, якщо сервер поверне дані з іншим часовим штампом, ніж той, який було отримано спочатку. Розглянемо додавання більш надійної обробки для сценаріїв застарілого часу»

Негайна реакція може бути захисною поясненням * чому * ви обрали цей підхід - можливо, підкреслюючи переваги продуктивності або простоту. Однак, цю відповідь можна легко неправильно інтерпретувати як відкидання занепокоєння. Ефективнішою стратегією є визнання дійсності зворотнього зв’ язку і визначення ваших дій за тими ж правилами, які б використовував рідний мовець. Замість того, щоб сказати: «Я оптимізував для швидкості; це цілком прийнятно», ви могли б відповісти: «Це дійсно хороша точка про застарілій час. Спочатку я зосередився на мінімізації затримки, але я безумовно можу включити більш явне керування — можливо, порівнюючи часовий штамп сервера з кешованою версією і викликаючи анульування, якщо є розбіжність. ” Зауважте зміну у формулюванні; це менше про затвердження вашого рішення і більше про демонстрацію розуміння і готовності пристосуватися.

Іншою частою ситуацією є розмови Slack, що обговорюють проблеми зневадження. Уявіть, що ви вирішуєте проблему, коли дані не оновлюється правильно після мутації. Друг у команді може написати: «Чи можете ви подвоїти перевірку, що параметр staleTime відповідає цьому конкретному запиту? Здається, що ми часто отримуємо застарілі дані. » Ключовим тут є визнання того, що « відповідний » не просто про числове значення; це про вирівнювання з очікуваною частотою оновлення даних і потенційною затримкою мережі. Скажімо, « Я встановив його на 5 секунд », але це не вирішить проблему, якщо швидкість відповіді сервера набагато швидша. Замість цього, ви відповіли б щось на зразок: «Гаразд, дозвольте мені перевірити часи відповіді сервера і відповідно змінити staleTime — я намагатимуся знайти значення, яке балансує швидкість відповіді зі свіжістю даних»

Нарешті, пам’ятайте, що чітке і коротке спілкування є найважливішим. Уникайте надмірно технічного жаргону під час пояснення концепцій іншим, особливо тим, хто менш знайомий з складностями TanStack Query. Спробуйте описати * що * ви робите і * чому *, а не просто вказати технічні деталі.

Ось короткий приклад використання tanstack-query у середовищі командного рядка:

npx @tanstack/query-client run dev start --url http://localhost:3001 --queries ./src/data/products.ts

За допомогою цієї команди можна запустити сервер розробки TanStack Query, який отримає дані з локальної кінцевої точки API і використає файли TypeScript для логіки доступу до даних. У цій статті показано практичне застосування словника, який буде розглянуто у цій статті — зокрема, запит даних за допомогою бібліотеки на стороні клієнта.