Стан діапазону за терміном існування: коли React Portal дійсно потребує глобального сховища

Команди, які створюють внутрішні портали, часто починають обговорення з питання „Redux чи Zustand?“. Кориснішим першим запитанням є те, які елементи стану дійсно потребують бути глобальними. У цій статті пояснюється, як класифікувати стан порталу за тим, хто ним керує та як довго він має існувати, чому розміщення тимчасового стану у глобальному сховищі призводить до постійних проблем із очищенням даних, та коли використання глобальної бібліотеки є правильним рішенням.

Більшість стану порталу є тимчасовими

Портали зазвичай є сукупністю окремих робочих процесів. Користувач відкриває сторінку, шукає чи редагує щось, завершує завдання та переходить до іншої частини додатку. Значення форм, фільтри, вибрані рядки таблиці, активна вкладка та наявність модального вікна — усе це належить до конкретної сторінки чи робочого процесу. Їм рідко потрібно зберігатися між кількома непов’язаними маршрутами.

Лише невелика кількість даних є справді загальнодоступною для всього додатку:

• залогований користувач;
• стан автентифікації та дозволи;
• текуща організація або користувач;
• переваги щодо теми та мови.

Майже все інше повинно залишатися біля функції, яка його створює.

Глобальні сховища перетворюють термін служби на завдання з очищення

Якщо помістити тимчасовий стан у Redux, Zustand, MobX або будь-яке інше глобальне сховище, він буде існувати довше, ніж екран, який його створив. Тепер потрібен додатковий код для скидання цього стану під час навігації, після надсилання даних, при виході з системи, коли змінюється користувач та при кожному іншому виході. Якщо пропустити якийсь етап, користувач повернеться на екран, де будуть відображатися застарілі фільтри, старі вибори чи неповні значення форми з попереднього візиту. Ці помилки важко відтворити, оскільки вони залежать від точної послідовності екранів, які відвідував користувач.

Основне правило досить просте: якщо глобальний стан постійно доводиться очищувати, щоб він поводився як локальний стан, ймовірно, його варто було з самого початку робити локальним.

Виберіть найменший можливий діапазон

Підберіть для кожної частини стану найвужчий інструмент, який охоплює весь період її існування:

• стан компонента для поведінки інтерфейсу, яка стосується окремого компонента;
• React Context для стану, який ділиться між однією функціональністю або групою пов’язаних маршрутів;
• параметри пошуку URL для фільтрів, сторінкування та іншого стану навігації, що також дозволяє делитися відображеннями та зберігати їх після оновлення;
• бібліотеку серверного стану, таку як TanStack Query, для даних, отриманих з сервера, адже кешування та скасування даних — це її завдання, а не завдання вашого сховища даних;
• глобальне сховище даних лише для клієнтського стану, який справді є загальним для всього додатку.

Слід особливо згадати контекст на рівні маршрутів. Коли ви розміщуєте провайдер навколо групи маршрутів, залишивши цю групу без обробки, провайдер демонтується, а його стан автоматично зникає. Життєвий цикл компонентів React виконує операції очищення, які інакше довелося б писати вручну. Якщо причина, чому ви звертаєтесь до стору, полягає справді у передачі пропсів через багато рівнів, це окрема проблема з простішими рішеннями, про які йдеться у чому передача пропсів через багато рівнів — це не причина для встановлення Redux чи Zustand.

Коли глобальний стор знаходить своє місце

Redux, Zustand та подібні бібліотеки є правильним вибором, коли стан має навмисно зберігатися на різних, не пов’язаних між собою екранах. Типові випадки включають:

• кошики для покупок;
• складні процеси оформлення замовлень, які охоплюють кілька сторінок;
• чернетки, які мають зберігатися;

додатки, орієнтовані на роботу поза мережею;

системи обміну повідомленнями чи сповіщень у всьому додатку;

функції скасування та повторення дій;

функції в реальному часі, де необхідно координувати стан клієнта;

складні робочі процеси з багатьма взаємозалежними переходами стану.

У таких ситуаціях централізований стан вирішує реальну проблему, а не створює її.

Ключові висновки

• Перш ніж обирати будь-яку бібліотеку, визначте власника та термін існування даних.
• Стан, який належить до певного робочого процесу, повинен зникати разом із цим процесом, бажано шляхом його від’єднання, а не ручного скидання.
• Зберігайте дані сервера у бібліотеці запитів, а стан навігації — у URL.
• Залиште глобальний сховище для даних, якими навмисно користується весь додаток протягом часу; знання того, коли його не використовувати, є частиною хорошої архітектури.