Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Які недоліки є в централізованого стора?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Централізований стор** ускладнює архітектуру застосунку, додає когнітивне навантаження й пов'язаний із ризиками глобального стану, труднощами lazy-loading, SSR та продуктивністю. **Ключове:** для невеликих застосунків стор часто надлишковий - можна обійтися props/emits, provide/inject або composables.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## Основні недоліки централізованого стора --- ### 1. **Ускладнення архітектури** Коли з'являється стор, архітектура стає: - складнішою - багатошаровою - менш очевидною для новачків Доводиться думати: - який стан має бути глобальним? - який - локальним? - куди винести бізнес-логіку? Якщо зробити сховище занадто «товстим», застосунок буде важко підтримувати. --- ### 2. **Додаткове когнітивне навантаження** Розробнику доводиться розуміти: - як працює стор - як пов'язані actions, state, getters - як дані течуть через застосунок Для невеликих застосунків це - **надлишкова складність**. --- ### 3. **Глобальність - це ризик** Глобальний стан: - живе весь час - доступний усім - може бути змінений неправильно (якщо архітектура порушена) - легко "перевантажує" пам'ять, якщо забути очистити дані Це призводить до: - важковловимих багів - забруднення стану - проблем при SSR (якщо стор не скидається) --- ### 4. **Труднощі з lazy-loading** Якщо застосунок модульний, потрібно грамотно підключати store-модулі ліниво. Неправильна конфігурація призводить до складнощів із поділом коду. У Vuex - це особливо чутливо. --- ### 5. **Надлишковість для невеликих застосунків** Для простого SPA можна обійтися: - props / emits - provide/inject - composables (Composition API) Стор може бути: - «гарматою по горобцях» - гірше читатися - складніше підтримуватися, ніж прості рішення --- ### 6. **Стор можна перетворити на «монолітне звалище»** Часта помилка: - складають усе в один модуль - стор розростається до сотень рядків - логіка змішується - складно зрозуміти, що за що відповідає Це робить застосунок менш масштабованим. --- ### 7. **Стор ускладнює SSR і гідратацію** Особливо Vuex: Потрібно: - окремо створювати стор для кожного запиту - уникати глобальних синглтонів - стежити за витоками Pinia вирішує це краще, але нюанси все одно є. --- ### 8. **Оверхед за продуктивністю** Кожна зміна глобального стану може викликати: - численні перемальовування - каскадні оновлення компонентів При неправильній архітектурі це призводить до лагів. --- ## Додаткові нюанси #### Важче тестувати компоненти Якщо компонент сильно залежить від стора. #### Потрібно думати про поділ модулів Інакше стор стане важко керованим. #### Не завжди очевидний потік даних Особливо у великих проєктах із розмитою межею «глобальне vs локальне».Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.