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

Qwik City — це мета- фреймворк, створений на основі Qwik, який додає файлове маршрутизацію, макети і звичаї завантаження даних до основної ідеї Qwik щодо « відновлюваності ». Оскільки вся концепція Qwik є відходом від гідрації моделі, більшість розробників інтерфейсу вже знають про це, пояснюючи це англійською мовою — якщо ви неправильно вимовите слова, ви випадково описаєте його як « ще один фреймворк SSR », коли справжнє значення знаходиться деінде. Цей посібник містить умови.

---

Основна ідея: відновлення

** Відновлюваність ** — центральна концепція Qwik: сервер надсилає повністю інтерактивну сторінку разом з серіалізованим станом програми, а переглядач « відновлює » виконання саме з того місця, де сервер його призупинив, без повторного запуску логіки компонента для приєднання слухачів подій.

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

** Гідраціонування ** — традиційний підхід (використовується більшістю платформ), за якого переглядач перезапускає все дерево компонентів після того, як сервер надіслав HTML, щоб додати слухачів подій і відновити стан.

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

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

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

---

Легке завантаження

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

“Обробник onClick$ для цієї кнопки знаходиться у власному блоку — його не завантажують взагалі, поки користувач не наведе вказівник миші на нього або не клацне по ньому.”

** $ суфікс (звичай знаку долара) ** — звичай присвоєння назв у Qwik, який позначає функцію або імпорт як межу лінивого завантаження, що дає змогу оптимізатору визначити, де слід розділити код.

“Все, що має назву з кінцевим $, наприклад component$ або onClick$, є підказкою для оптимізатора Qwik про те, де створити межу, яку можна завантажити ліниво.”

---

Місто Квебек

Файлові маршрутизації

Файлове маршрутизування відображає файли всередині src/routes безпосередньо на URL-шляхи, подібно до Next.js або SvelteKit, але шарувато на вершині моделі відтворення Qwik.

“Додання нової сторінки — це просто додавання нового файла під src/routes — немає окремого файла налаштування маршруту для оновлення.”

Маршрутний зарядник

На сервері виконується програма ** route loader ** ( routeLoader$ ), яка отримує дані для маршруту перед відтворенням, показуючи ці дані компоненту у повністю типованому вигляді.

• “Загрузчик маршрутів отримує дані про продукт з боку сервера — компонент просто викликає повернений гачок і отримує повністю введені дані назад.” *

Action

Дія ** route ** ( routeAction$ ) обробляє подачу і мутації форм на сервері, інтегруючи з прогресивними розширеннями, щоб форми працювали навіть перед завантаженням JavaScript.

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

Layout

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

“Розклад панелі обгортає кожен маршрут під /dashboard, тому ми не повторюємо розмітку бічної панелі на кожній сторінці.”

---

Словник швидкодії, специфічний для Qwik

** Час до інтерактивності (TTI) ** — традиційно, це час, протягом якого сторінка стає повністю інтерактивною після завершення гідрації; з можливістю відновлення, Qwik стверджує, що ця вартість у значній мірі виключена, оскільки немає кроку гідрації, що блокує інтерактивність.

“Наші цифри TTI на цій сторінці близькі до нуля, оскільки фактично немає жодного кроку гідрації, який потрібно виконати, щоб користувачі могли взаємодіяти.”

** Прогресивно розширено ** — створення можливості (наприклад, форми), яка спочатку працюватиме з базовою поведінкою HTML, а потім буде розширено за допомогою JavaScript після завантаження — критичне для того, щоб дії Qwik City були правильними навіть за повільних з’ єднань.

“Навіть при 3G з’ єднанні, подача форми все ще працює - це прогресивне поліпшення, а не резерв, який ми встановили окремо.”

---

У місті розташований КВК «Кременчук»

Situation	Phrase
Explaining resumability to a skeptical teammate	”It’s not that we’ve optimised hydration — there’s no hydration step at all. The browser resumes exactly where the server stopped.”
Justifying route loaders over client-side fetching	”The route loader runs server-side before the page renders, so there’s no loading spinner or waterfall — the data is already there.”
Describing the $ convention	”Every $ suffix marks a lazy-loading boundary — it’s the compiler’s signal for where code can be split and deferred.”
Explaining a serialization bug	”We passed a non-serializable value across a component boundary — the fix was to move that logic inside a $-wrapped function instead.”

Поширені помилки

• Описуючи Qwik City як «SSR з кращою гідрацією» — відмінною заявою є **відсутність ** кроку гідрації, а не його швидша версія.
• Забув пояснити ** $ конвенцію ** при перегляді нового коду колеги — без контексту, це виглядає як довільне ім’я, а не сигнал компілятора.
• Виклик завантажувача маршрутів « getServerSideProps equivalent » без позначення повертає типований, реактивний ресурс, а не одноразовий ресурс.

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

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

Зв’язані ресурси

• Англійська для розробників Qwik
• Англійська для астрономічних островів архітектури
• Англійська для розробників SolidJS

На практиці: Навігація нюансів зворотного зв’язку і співпраці

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

Зазвичай, цей сценарій передбачає перегляд запиту на завантаження, який містить новий завантажувач маршрутів. Старший розробник може залишити коментар на зразок: « Цей завантажувач маршрутів функціональний, але я хвилююся щодо його впливу на початкові часи завантаження. Чи можете ви дослідити використання prefetch для поліпшення користувацького досвіду? “Це не звинувачення; це пропозиція, вкладена в технічну проблему - продуктивність. Ключовим тут є визнання зусиль розробника, одночасно нежно направляючи їх до більш оптимізованого рішення. Аналогічно, в обговореннях Slack, ви можете побачити такі фрази, як «Подумаємо про це як про потенційне вузьке місце» або «Чи можемо ми переробити, щоб зменшити розмір пакунка?» Це складні способи вирішення технічного боргу і запропонувати поліпшення, не звучачи надто критичним. Пам’ятайте, співпраця процвітає на ясному, уважному спілкуванні.

Інша поширена ситуація виникає при описі мети нової дії у завантажувачі маршрутів. Замість того, щоб просто сказати « Ця дія отримує дані », розгляньте щось на зразок: « Ця дія отримує інформацію про профілі користувачів під час початкового завантаження сторінки, щоб надати негайний контекст і поліпшити інтерфейс користувача ». Додаткові подробиці надають важливі знання про те, * чому * виконується отримання певних даних, що допомагає команді зрозуміти загальну мету проектування. Крім того, при написанні описів PR, будьте конкретними щодо змін, які ви зробили, і їх очікуваного ефекту. Хорошим прикладом може бути: « Впроваджено новий завантажувач маршрутів для /profile, щоб отримати дані користувача за допомогою qwik-data, поліпшити швидкість завантаження початкової сторінки ». Це поєднує технічну термінологію (механізм отримання даних Qwik City) з чітким описом переваги — поліпшення швидкості.

Нарешті, не соромтеся ставити питання, якщо щось не відразу стає очевидним. « Чи могли б ви розібратися у причині використання prefetch тут? » демонструє зацікавленість і переконує, що всі розуміють одне й те саме. Вміння чітко формулювати технічні рішення і отримувати конструктивний зворотній зв’ язок є основою успішної командної роботи з розробкою.

# Example: Using Qwik City's data fetching API (simplified)
qwik-data prefetch userProfile(userId) {
  return fetch(`/api/users/${userId}`)
    .then(response => response.json())
    .catch(error => { console.error("Error fetching user:", error); return null; });
}