5 ошибок в SvelteKit, из-за которых SSR начинает тормозить и путать команду
SvelteKit удобен ровно до момента, пока проект не смешивает server-side и client-side логику без границ. Самые частые провалы:
— тянуть данные в +page.svelte вместо load, а потом дублировать запросы;
— читать window/document в коде, который выполняется на сервере;
— хранить тяжёлое состояние в компоненте вместо параметров URL или server stores.
Ещё одна типовая ловушка — навигация и формы. Если после submit вы сразу лезете в DOM-эффекты, можно поймать гонки и странные перерисовки. Лучше сначала разложить поток: данные приходят через load, изменения проходят через actions, UI реагирует на результат, а не наоборот. Это особенно заметно в сложных кабинетах и админках.
Для поддержки проекта полезно сразу договориться о трёх правилах:
— весь доступ к внешним API и секретам держать на сервере;
— клиентский код выносить в onMount и отдельные компоненты;
— тяжёлые вычисления не прятать в реактивность без нужды ⚙️
Если это соблюдать, SvelteKit остаётся быстрым и предсказуемым: меньше дублей запросов, меньше сюрпризов при SSR, проще дебажить путь данных от запроса до экрана.
Attribution Deep
@attribution_deep
5 ошибок в SvelteKit, из-за которых SSR начинает тормозить и путать команду
Этот пост опубликован в Telegram-канале Attribution Deep. Подписаться можно по ссылке: @attribution_deep.