Shower Presentation Engine

Порой разработчики создают новые абстракции, которые ведут к значительному усложнению. Иногда эти абстракции отдаляют их от оптимального решения на многие годы!
Эта история об одном таком случае, который, к счастью, завершился благополучно.

• компактный
• простой в подключении
• простой в использовании
• не добавляющий когнитивной нагрузки
• активно доставляющий изменения в представление
• производительный
• легко оптимизируемый
• легко масштабируемый
• имеющий легко коддерживаемый код
• исключающий проблемы типа Zombie children и context loss
• поддерживающий работу React concurency mode

Преимущества: простота

Недостатки: главным недостатком является не боль в пальцах при поддержке такого кода, а то, что глобальные переменные никогда не удаляются из памяти, их много и они не связаны логически между собой!

Понятие бизнес-логики изменения состояния отсутствует

Преимущества: состояние оформлено в одну сущность

Недостатки:

• хранение в глобальной переменной
• изменения не распространияются активно в точки потребления информации
• бизнес-логика изменения данных размазана по коду

Преимущества:

• состояние структурировано по моделям
• логика изменения данных инкапсулирована в модели
• изменения состояния активно "влияют" на представления

Недостатки:

• огромное количество моделей в приложении
• связи между моделями и другими сущностями не контролируемы
• поток данных разнонаправленный, не обозреваемый и не контролируемый
• бизнес-логика управления данными размазана по всему коду
• рано или поздно возникают зацикливания при распространении изменений
• OOП - это много бойлерплейта и не производительно
• рефакторинг такого кода - это кошмар разработчика - большая хрупкость

Создание однонаправленного контролируемого и предсказуемого потока данных: представления -> канал данных -> модели -> представления

Для того, чтобы различать данные для разных сторов (моделей) в канале - данные снабдили метаданными и назвали этот тип данных Action

Преимущества:

• единственный однонаправленнный поток данных
• и этот поток данных - контролируемый

Недостатки:

• это не фреймворк + дополнительная когнитивная нагрузка
• сложно настраивается и много шаблонного кода
• большое количество сторов, связи между ними не очевидны
• по-прежнему много кода для поддержки связей между сторами
• необходимость ожидания изменений в сторах в цепочке изменений
• бизнес-логика размазана в коде изменений в сторах и между ними

Изменения:

весь зопарк сторов с их не прозрачной логикой обновления заменили единым стором (полная аналогия с БД) и централизованной чистой логикой его изменения.

Добавили middleware для обработки бизнес-логики и сайд-эффектов

Преимущества:

• фреймворк, строго определяющий правила поведения и реализации
• единственный однонаправленнный поток данных
• единственный стор c чистой и прозрачной логикой изменений
• бизнес-логика и логика обработки сайд-эффектов обособлена
• код приложения стал относительно простым и легко и безопасно изменяем

Недостатки:

• добавляет большую когнитивную нагрузку
• относительно сложно настраивается в приложение
• не удобно работать с бизнес-логикой и сайд-эффектами
• из-за этого бизнес логика расползается по приложению
• имеет относительно много бойлерплейта
• оптимизация порой не тривиальна
• плохо масштабируется

Чего удалось достичь:

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

Чего не удалось достичь:

• отсутствия дополнительной когнитивной нагрузки
• простоты в интеграции
• простоты в использовании
• отсутствия бойлерплейта
• простоты в оптимизации
• инкапсуляции логики изменения данных в сторе
• масштабируемости

Небольшое, быстрое и масштабируемое решение для управления состоянием, основанное на принципах Flux и immutable state (как и React).

В его основе лежит хранилище основанное на базе publish/subscribe.

Имеет удобный API, основанный на хуках, не создает лишнего шаблонного кода и не навязывает жестких правил использования.

Не имеет проблем с Zombie children и context loss и отлично работает с React concurrency mode

Как и в Redux вы можете написать для хранилища свои middleware, которые будут обрабатывать события и изменять состояние хранилища.

Zustand предлагает в пакете такие middleware как:

• persist - для сохранения/восстановления данных в/из localStorage
• immer - для простого мутабельного изменения состояния
• devtools - для работы с раширением redux devtools для отладки

Используя статические методы хука:

• .getState()
• .setState()
• .subscribe()

вы получаете доступ к стору из любого окружения: как из методов стора, обработчиков событий React компонент, так и из vanilla JavaScript.

При этом вы свободно можете использовать асинхронную обработку данных и любые сайд-эффекты!💥💥💥

• если селектор не зависит от внутренних переменных - вынесите его за пределы компонента, чтобы не пересоздавать хук каждый раз
• если селектор имеет параметры - заключите его в useCallback
• если селектор возвращает каждый раз новый объект - оберните вызов селектора в useShallow
• использовать прямую подписку на изменения в обход жизненного цикла React

Если даже с параметрами ваш селектор может возвращать новый объект - оберните селектор в 2 хука: useCallback и useShallow

• компактный
• простой в подключении
• простой в использовании
• не добавляющий когнитивной нагрузки
• активно доставляющий изменения в представление
• производительный
• легко оптимизируемый
• легко масштабируемый
• имеющий легко коддерживаемый код
• исключающий проблемы типа Zombie children и context loss
• поддерживающий работу React concurency mode

Фронтенду пришлось 10 лет бродить по технологическим дебрям, чтобы прийти к тому, к чему мы пришли сегодня с Zustand!

Pub/sub был в MV* с незапамятных времен - нам оставалось лишь выделить в абстракцию селектор, объединить все модели в один стор и оформить аналог хука!
Но на том повороте мы свернули не туда и пошли не за теми ...

В последнее время у новичков, кто руками не проходил стадию развития с использованием MV*, наблюдается тенденция наступать на те грабли, что индустрия уже давно прошла: model hell - появляются различные амёбные, молекулярные, атомные и кварковые "стейт-менеджеры"

Использование отдельных хранилищь оправдано лишь:

• для набора не связанных сущностей^*
• для частей проекта, разрабатываем разными командами^*

^* - когда реально нет пересечений запросов к этим сущностям

Вопреки примерам из документации, рекомендую не создавать методы хранилища внутри него - если у вас в хранилище много сущностей или сущности сложные, а их методы обработки достаточно объемные - описание вашего хранилища станет не читаемым, не понимаемым и плохо поддерживаемым.

Если хотите иметь надежное приложение с минимумом багов - никогда!, никогда не давайте доступ к хранилищу разрабочкикам в обход его методов!

Проблема подавляющего большинства проектов заключается в том, что никто не соблюдает правило единственной отвественности - логика валидации и изменения данных размазана по всему коду, а хранилище используется исключительно как хранилище json! Отсюда и 99% багов в приложении.

Хранилище должно валидировать данные на входе, сериализивать их, проверить ссылочную целостность внутри и только после этого обновлять их и отдать их обратно сериализированными - только в этом случае вы получите не убиваемое ядро приложения и надежное приложение!

Инкапсуляция бизнес-логики в методах стора позволит безболезненно менять стейт-менеджер - приложение использует только методы сторов!

Перевод проекта с Redux на Zustand произошел очень быстро и без проблем - благодаря сходству семантики в обоих подходах (отправка actions/вызов методов хранилища и использование хуков) при переходе не возникало никаких проблем.

Параллельно хранилищу Redux было создано хранилище Zustand и постепенно все сущности без боли переносились в новый стор.

Самое главное - разработчики делали это с большим удовольствием и даже не просили денег за это! 😊

Сказать о том, что разработка с Zustand упростилась - это не сказать ничего!

Благодаря Zustand вся логика, связанная с доменными сущностями была собрана в хранилище. Используя Zustand вместе с "прагматичной архитектурой" (тема отдельного доклада) мы почти избавились от тестов (мы пишем их по минимуму) - в коде практически не осталось места для багов!

Мы отдали на откуп джуниоров создание визуала - они создают компоненты, логику отображения и сражаются со storybook - данные же подключаются к компонентам одной строчкой в контейнерах!
Код проекта стал структурированным, простым и понимаемым, а в проекте мы практически избавились от багов!

Начинайте активно в своих проектах переходить на самый простой, самый современный и самый быстрый стейт-менеджер - он существует уже несколько лет! Сделайте себе и людям хорошо!

Используйте Zustand совместно с правильной архитектурой приложения и будет вам счастье!