Стиль коду в Nuxt 3 та 4: найкращі практики

Чистий код у Nuxt — це не про форматування. Це про передбачувану структуру, безпечну реактивність і чіткі межі між app, server та спільним кодом. Ось практичний чекліст, якого я тримаюся в кожному Vue 3 / Nuxt 3–4 проєкті.

Компоненти та реактивність

• Використовуйте <script setup lang="ts"> усюди. Це найлаконічніший повністю типізований синтаксис Composition API і стандарт для сучасного Nuxt.
• Деструктуруйте props безпечно. У сучасному Vue деструктуризація з defineProps зберігає реактивність, але якщо потрібне значення за замовчуванням, що лишається реактивним, використовуйте reactive props destructure або toRef — ніколи не читайте деструктурований prop як звичайну копію.
• Використовуйте defineModel() для двостороннього звʼязування замість старого шаблону prop + emit('update:..').
• Тримайте бізнес-логіку поза шаблонами. Шаблон описує UI; умови й перетворення виносьте в computed або композабли.
• Тримайте компоненти малими й сфокусованими. Якщо компонент відповідає за кілька речей — розділіть його.

Стан і стори (Pinia)

• Не деструктуруйте Pinia-стор напряму — втратите реактивність. Використовуйте storeToRefs() для стану й гетерів, а деструктуруйте лише екшени.
• Тримайте стори за доменами (один стор на бізнес-домен), а не один гігантський глобальний стор.

Перевикористання логіки по-нуксовому

• Виносьте повторювану логіку в композабли (useX), а не дублюйте її між компонентами.
• Користуйтеся авто-імпортами, але тримайте імена зрозумілими. Авто-імпорт потужний; явні описові назви рятують від «магії».
• Використовуйте директорію shared/ для коду, спільного для app і server, щоб універсальні хелпери жили в одному місці.
• Відокремлюйте код app від коду server. Серверна логіка живе в server/ і ніколи не потрапляє в клієнтський бандл.

Отримання даних і типи

• Свідомо обирайте useFetch чи useAsyncData. useFetch — для простих запитів, useAsyncData — коли потрібні власні ключі, трансформації чи контроль кешу.
• Типізуйте відповіді API. Описуйте інтерфейси того, що повертає бекенд, замість any.
• Валідуйте важливі дані (форми, query-параметри, вебхуки) схемою на кшталт Zod, перш ніж їм довіряти.

Конвенції проєкту

• Для великих застосунків віддавайте перевагу feature-based папкам, а не поділу суто за типом файлів.
• Давайте компонентам явні імена, щоб їх легко було знаходити й дебажити.
• Стандартизуйте форматування та лінтинг (ESLint + Prettier), щоб стиль був автоматичним, а не темою для рев'ю.
• Правильно читайте runtime config — тримайте секрети на сервері й віддавайте клієнту лише потрібне через runtimeConfig.public.
• Віддавайте перевагу читабельному коду, а не «розумному».

Памʼятайте: чистий код — це не про правила. Це про ясність, підтримуваність і полегшення життя наступному розробнику.