Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Коли локальний стан кращий за глобальний?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Локальний стан** краще за глобальний, коли він потрібен лише одному компоненту, тимчасовий або стосується UI-поведінки (модалка, вкладки, ховер). **Ключове:** якщо кожен екземпляр компонента повинен мати власну копію даних, а props/emit достатньо для керування, глобальний store лише ускладнить код.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Якщо стан впливає лише на UI і поведінку конкретного компонента - він має бути локальним.** Це головний принцип. Тепер розберемо детально. --- ## Коли локальний стан кращий? ### 1) Коли дані потрібні лише одному компоненту Приклади: - стан форми (`email`, `password`) - відкритий/закритий dropdown у картці - вибрана вкладка всередині компонента - локальний лічильник (`count`) - стан input (`value`, `isFocused`) Глобальний стан тут не потрібен - лише ускладнить застосунок. --- ### 2) Коли стан тимчасовий Наприклад: - стан модалки (відкрити/закрити) - тимчасовий прапорець завантаження (`isLoading`) - стан ховеру (`isHovered`) - виділений елемент у списку Ці дані живуть лише поки компонент на екрані. --- ### 3) Коли стан не має бути спільним Якщо кожен екземпляр компонента повинен мати свою копію даних. Приклад: ```javascript <TodoItem /> <TodoItem /> <TodoItem /> ``` Кожен елемент списку повинен мати власний стан (відкритий/закритий, виділений, режим редагування). Якщо зробити глобально -> логіка ламається. --- ### 4) Коли стан не потрібно "передавати вниз" і "не потрібен іншим" Якщо дані не перетинаються між компонентами -> тримай локально. --- ### 5) Коли легко керувати через props/emit Приклад: ```javascript <Modal :is-open="modalOpen" @close="modalOpen = false" /> ``` Навіщо глобальний store? Достатньо батьківського компонента. --- ### 6) Коли глобальний стан ускладнює архітектуру Іноді store створює більше проблем, ніж вирішує: - більше коду - більше залежностей - складніше підтримувати - складніше тестувати Якщо дані прості - не потрібно виносити їх у Pinia. --- ## Коли НЕ варто виносити локальний стан у глобальний? Якщо: #### цим станом не користується більше одного компонента #### це UI-стан (модалка, вкладки, меню) #### компонент повинен мати власну копію state #### дані не потрібні при зміні сторінки #### немає потреби синхронізувати кілька компонентів Часта помилка джунів - "тягнути все в глобальний store". Це робить застосунок складним і роздутим. --- ## Приклади конкретних ситуацій ### Добре: локальний стан ```javascript <script setup> const isOpen = ref(false) </script> <template> <button @click="isOpen = !isOpen">Toggle</button> <p v-if="isOpen">Hello!</p> </template> ``` Нікому, крім цього компонента, він не потрібен. --- ### Погано: винести це у Pinia Такий стан не можна робити глобальним - це UI локальної поведінки. --- ### Добре: локальний стан форми ```javascript const email = ref('') const password = ref('') const errors = reactive({}) ``` Не потрібно зберігати це у store - це локальна логіка. --- ## Підсумок (коротко) **Локальний стан кращий за глобальний, коли:** - потрібен лише одному компоненту - стан тимчасовий - поведінка стосується UI - кожен екземпляр повинен мати свій стан - props/emit достатньо - global store лише ускладнить код **Глобальний - лише коли дані спільні для багатьох частин застосунку.**Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.