71 - React JS - setState, local state
Почему мы выбрали Zustand❓ Как я упомянул в предыдущем посте о Zustand, мы начали его использовать в июне 2021 года. До этого использовали просто useState/useReducer/useContext, поняли что так больше нельзя, и перед разработкой новой большой фичи мы начали искать подходящий менеджер состояний. У нас были следующие требования: 1. Использование состояния между компонентами, у которых нет общего родительского компонента. Мы мигрируем с JQuery на React, поэтому большинство компонентов рендерятся с помощью createRoot и не имеют общего родителя, что не позволяет использовать контекст реакта и совместно использовать состояние между компонентами 2. Атомарные обновления, чего нет у контекста реакта 3. Поддержка асинхронных обновлений стейта вне компонента. Чтобы избегать ошибок типа Can't perform a React state update on an unmounted component, которые происходят, когда обновляется состояние для уже удалённого компонента 4. Поддержка Computed Properties 5. Поддержка TypeScript 6. Тестируемость 7. Маленький размер бандла 8. Англоязычное комьюнити, потому что команда англоязычная И следующий 2 требования я выделю отдельно: 1. Простота использования. Очень важно, когда у вас разработчики со всех концов света и скилы у всех разные. К тому же, очень просто наговнокодить, когда вы начинаете использовать новый инструмент. 2. Возможность использовать вне реакта. Как я уже упомянул, мы мигрируем с JQuery на React, поэтому мы хотели использовать стейт менеджер и в легаси коде. Это позволило бы: - мигрировать глобальный стейт в новую кодовую базу и использовать во всём приложении - управлять реакт компонентами из JQuery, просто меняя стейт. 1️⃣ В первоначальном списке оказались: - Redux - MobX - Recoil - Zustand - Jotai - Akita - Effector 2️⃣ После анализа, в следующем раунде отбора оказались: MobX, Recoil и Zustand. Recoil попал по блату, его проталкивал один из членов команды, и потому что он разработан в стенах авторитетной “запрещённой” организации. Мы переписали один и тот же небольшой компонент на MobX, Recoil и Zustand, чтобы проверить их в деле: ❌ MobX. По большей части нам не понравилось, что каждый компонент нужно оборачивать в observer, если он использует observable объект. К тому же, у него не самый простой API. ❌ К Recoil было очень много вопросов. Начиная от того, что он жирный — почти 80Кб без GZip и заканчиваю тем, что нельзя просто взять и вынести из компонента асинхронные обновления стейта. С асинхронным получением данных всё понятно, там есть селекторы, но как асинхронно обновить стейт — хз. К тому же он не production ready. ✅ Zustand нам понравился своей простотой, чтобы понять код – даже не нужно смотреть документацию. Также круто, что он удовлетворял буквально каждому нашему требованию. Если вы ещё не знакомы с Zustand, то обязательно посмотрите видео из предыдущего поста. А если вам в целом интересна тема стейт менеджеров — то подписывайтесь на Артёма — автора реатома. P.S. Кстати, Zustand прост не только в использовании, его исходники тоже просты как дважды два — четыре. Лучше понять, как он работает под капотом поможет статья Как работает Zustand. #frontend #react #statemanagement #zustand
Shared State для React. Часть 1
В данном цикле статей мы рассмотрим задачу синхронизации состояния приложения между окнами. В качестве подопытного у нас будет приложение на Electron, работающее в offline/online-режимах, которое также может запускаться в PWA-режиме. Дано Итак. У нас на руках есть довольно богатое приложение, написанное на TypeScript, React + Redux. Запускать мы его умеем в среде Electron (это платформа на основе браузера Chrome, чтобы делать полноценные портабельные приложения — хоть для Mac, хоть для Windows или Linux — у нас все это есть)...