diff --git a/docs/index.html b/docs/index.html index 7f3f822..964da8e 100644 --- a/docs/index.html +++ b/docs/index.html @@ -1,156 +1,157 @@ - - - Shower Presentation Engine - - - - - - - -
-

Shower Presentation Engine

-

Yours Truly, Famous Inc.

-
- -
+ + Shower Presentation Engine + + + - -
-

Zustand.js пришел изменить все правила игры!

-

Забудьте все, что вы знали о стейт-менеджерах прежде.

-
- - https://clck.ru/38F2VS -
-
- -

Вступительное слово

-
-
- Сложность в программировании никуда не исчезает - она лишь - перераспределяется и перетекает из одной формы в другую -
-
© undefined
-
-
-

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

-
-
+ -
-

Идеальный стейт-менеджер: какой он?

-
- -
-
+ +
+

Shower Presentation Engine

+

Yours Truly, Famous Inc.

+
+ +
+ + +
+

Zustand.js пришел изменить все правила игры!

+

Забудьте все, что вы знали о стейт-менеджерах прежде.

+
+ + https://clck.ru/38F2VS +
+ +
+ +

Вступительное слово

+
+
+ Сложность в программировании никуда не исчезает - она лишь + перераспределяется и перетекает из одной формы в другую +
+
© undefined
+
+
+

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

+
+
+ +
+

Идеальный стейт-менеджер: какой он?

+
+ +
+
- - -
-

Ретроспектива развития стейт-менеджеров

-

Лапша-код

+
+

Ретроспектива развития стейт-менеджеров

+

Лапша-код

+ +

А кто его не писал?

+

Состояние приложения хранилось во множестве глобальных переменных

-

А кто его не писал?

-

Состояние приложения хранилось во множестве глобальных переменных

+
+
+

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

+

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

+

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

+
+
-
-
-

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

+
+

Ретроспектива развития стейт-менеджеров

+

Лапша-код: объект как хранилище состояния

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

-

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

-
-
-
-

Ретроспектива развития стейт-менеджеров

-

Лапша-код: объект как хранилище состояния

-

- Состояние приложения хранится в одном объекте типа - appConfig -

+
+
+

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

+

Недостатки:

+ +
+
-
-
-

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

-

Недостатки:

- -
- +
+ +

Ретроспектива развития стейт-менеджеров

+

MV*

-
- -

Ретроспектива развития стейт-менеджеров

-

MV*

+

Теория

+ +
-

Теория

- -
+
+

Ретроспектива развития стейт-менеджеров

+

MV*

+

Состояние приложения хранится в модели

-
-

Ретроспектива развития стейт-менеджеров

-

MV*

-

Состояние приложения хранится в модели

+
+
+

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

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

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

- -
-
+
+ +

Ретроспектива развития стейт-менеджеров

+

MV*

-
- -

Ретроспектива развития стейт-менеджеров

-

MV*

+

Реальность

+ +
-

Реальность

- -
+
+

Ретроспектива развития стейт-менеджеров

+

MV*

+

Состояние приложения хранится в модели

-
-

Ретроспектива развития стейт-менеджеров

-

MV*

-

Состояние приложения хранится в модели

+
+

Недостатки:

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

Недостатки:

- -
-
+
+

Ретроспектива развития стейт-менеджеров

+

Flux

+

Однонаправленный поток данных

+
+
+

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

+

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

+
+
-
-

Ретроспектива развития стейт-менеджеров

-

Flux

-

Однонаправленный поток данных

-
-
-

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

-

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

-
-
+
+ +

Ретроспектива развития стейт-менеджеров

+

Flux

+

Однонаправленный поток данных

+ +
-
- -

Ретроспектива развития стейт-менеджеров

-

Flux

-

Однонаправленный поток данных

- -
- -
-

Ретроспектива развития стейт-менеджеров

-

Flux

-

Однонаправленный поток данных

-
-
-

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

- -
-
+
+

Ретроспектива развития стейт-менеджеров

+

Flux

+

Однонаправленный поток данных

+
+
+

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

+ +
+
-
-

Ретроспектива развития стейт-менеджеров

-

Flux

-

Однонаправленный поток данных

+
+

Ретроспектива развития стейт-менеджеров

+

Flux

+

Однонаправленный поток данных

-
-
-

Недостатки:

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

Недостатки:

+ +
+
-
-

Ретроспектива развития стейт-менеджеров

-

Redux

-

Это - Flux с единым стором и логикой по его обновлению

-
-
-

Изменения:

-

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

-

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

-
-
+
+

Ретроспектива развития стейт-менеджеров

+

Redux

+

Это - Flux с единым стором и логикой по его обновлению

+
+
+

Изменения:

+

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

+

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

+
+
-
- -

Ретроспектива развития стейт-менеджеров

-

Redux

-

Это - Flux с единым стором и логикой по его обновлению

- -
- -
-

Ретроспектива развития стейт-менеджеров

-

Redux

-

Это -Flux с единым стором и логикой по его обновлению

-
-
-

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

- -
-
+
+ +

Ретроспектива развития стейт-менеджеров

+

Redux

+

Это - Flux с единым стором и логикой по его обновлению

+ +
-
-

Ретроспектива развития стейт-менеджеров

-

Redux

-

Это -Flux с единым стором и логикой по его обновлению

+
+

Ретроспектива развития стейт-менеджеров

+

Redux

+

Это -Flux с единым стором и логикой по его обновлению

+
+
+

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

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

Недостатки:

- -
-
+
+

Ретроспектива развития стейт-менеджеров

+

Redux

+

Это -Flux с единым стором и логикой по его обновлению

+ +
+

Недостатки:

+ +
+
-
-

Ретроспектива развития стейт-менеджеров

-

Итоги развития

+
+

Ретроспектива развития стейт-менеджеров

+

Итоги развития

-
-
-

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

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

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

+ +
+
-
-

Ретроспектива развития стейт-менеджеров

-

Итоги развития

+
+

Ретроспектива развития стейт-менеджеров

+

Итоги развития

-
-
-

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

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

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

+ +
+
- -
- -

Zustand.js 🚀

- - Нирвана - простота - масштабируемость - производительность - лафа для разработчика! -
- -
-

Zustand.js

-

Давайте знакомиться

- -
-
-

- Небольшое, быстрое и масштабируемое решение для управления состоянием, - основанное на принципах Flux. -

-

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

-

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

-

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

-
-
+ .flow4 { + position: absolute; + top: 510px; + right: 50px; + color: white; + } + +

Zustand.js 🚀

+ + Нирвана + простота + масштабируемость + производительность + лафа для разработчика! + + +
+

Zustand.js

+

Давайте знакомиться

-
- -

Zustand.js

-

Воздушный

- -
+
+
+

+ Небольшое, быстрое и масштабируемое решение для управления состоянием, + основанное на принципах Flux. +

+

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

+

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

+

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

+
+
-
- +

Zustand.js

+

Воздушный

+ +
- pre { - --slide-side: 0; - } +
+ -

Zustand.js

-

Простой в настройке и использовании

+ pre { + --slide-side: 0; + } + + .slide pre code:not(:only-child)::before { + content: none; + } + +

Zustand.js

+

Простой в настройке и использовании

- 
+      
       const storeHook = create((set, get) => { store_config })
       storeHook: (selector) => selectedState
       selector: (state) => ({ извлечённые данные из state })
@@ -612,105 +615,105 @@ 
Простой в настройке и использовании

       storeHook.setState: (newState) => void
       storeHook.subscribe: (callback) => void
     

-
+ -
- -

Zustand.js

-

Хранилище очень легко создавать

- -
+
+ +

Zustand.js

+

Хранилище очень легко создавать

+ +
-
- -

Zustand.js

-

Можно создавать сколько угодно хранилищ

- -
+
+ +

Zustand.js

+

Можно создавать сколько угодно хранилищ

+ +
-
- -

Zustand.js

-

В хранилище можно использовать асинхронные методы

- -
+
+ +

Zustand.js

+

В хранилище можно использовать асинхронные методы

+ +
-
- -

Zustand.js

-

Хранилище очень легко использовать в компонентах

- -
+
+ +

Zustand.js

+

Хранилище очень легко использовать в компонентах

+ +
-
- -

Zustand.js

-

Вы можете делать даже так! Но лучше так не делать 😊

- -
+
+ +

Zustand.js

+

Вы можете делать даже так! Но лучше так не делать 😊

+ +
-
-

Zustand.js

-

Middlewares

+
+

Zustand.js

+

Middlewares

-
-
-

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


-

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

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

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

+
+

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

+ +
+
- -
- -

Zustand.js

-

А что под капотом? Куда уж проще!?

- -
+
+ +

Zustand.js

+

А что под капотом? Куда уж проще!?

+ +
-
- -

Zustand.js

-

Реальная реализация хука

- -
+
+ +

Zustand.js

+

Реальная реализация хука

+ +
-
-

Zustand.js

-

Хранилище можно использовать везде и с любым типом кода!

+
+

Zustand.js

+

Хранилище можно использовать везде и с любым типом кода!

-
-

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

- +
+

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

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

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

+

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

+
+
+ +
+

Zustand.js

+

Методы оптимизации производительности

+
+

Всего 4 простых метода:

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

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

-

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

-
-
- -
-

Zustand.js

-

Методы оптимизации производительности

-
-

Всего 4 простых метода:

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

Zustand.js

-

Оптимизация: вынос селектора за пределы компонента

- -
+
+ +

Zustand.js

+

Оптимизация: вынос селектора за пределы компонента

+ +
-
- -

Zustand.js

-

Оптимизация: оберните в useCallback селектор с параметрами

- -
+
+ +

Zustand.js

+

Оптимизация: оберните в useCallback селектор с параметрами

+ +
-
- -

Zustand.js

-

- Оптимизация: оберните в useShallow селектор возвращающий каждый раз - новый объект -

- -
- -
- -

Zustand.js

-

Оптимизация: самый тяжелый случай

+
+ +

Zustand.js

+

+ Оптимизация: оберните в useShallow селектор возвращающий каждый раз + новый объект +

+ +
+ +
+ +

Zustand.js

+

Оптимизация: самый тяжелый случай

-
-

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

- -
-
+
+

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

+ +
+
-
- -

Zustand.js

-

Производительность на максималках

+
+ +

Zustand.js

+

Производительность на максималках

-

Используем механизм подписок без лишних перерисовок

- -
+

Используем механизм подписок без лишних перерисовок

+ +
-
- -

Итого: Zustand - мечта разработчика!

-
- -
-
+ .slide ul.succes > li:lang(ru)::before { + content: none; + } + +

Итого: Zustand - мечта разработчика!

+
+ +
+ -
- -

Zustand.js

-

Немного размышлений

+ .slide blockquote + figcaption { + margin: auto; + } + +

Zustand.js

+

Немного размышлений

-
-
- Не каждый (если никто), чей голос громче всех звучит, или кто у всех - на виду или в авторитете - есть Моисей! -
-
© typeof Object
-
+
+
+ Не каждый (если никто), чей голос громче всех звучит, или кто у всех + на виду или в авторитете - есть Моисей! +
+
© typeof Object
+
-
-

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

-

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

-
-
+
+

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

+

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

+
+ -
-

Рекомендации

-

1. Все связанные сущности держите в одном хранилище

+
+

Рекомендации

+

1. Все связанные сущности держите в одном хранилище

-
-

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

-

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

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

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

-
-
+
+

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

+

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

+ +

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

+
+
-
- -

Рекомендации

-

2. Методы хранилища создавайте вне его описания

+
+ +

Рекомендации

+

2. Методы хранилища создавайте вне его описания

-
-

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

-
- -
+
+

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

+
+ +
-
- -

Рекомендации

-

3. Доступ к данным в хранилище только при помощи его методов!

+
+ +

Рекомендации

+

3. Доступ к данным в хранилище только при помощи его методов!

-
-

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

-
- -
+
+

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

+
+ +
-
-

Рекомендации

-

4. Создавайте настоящее хранилище данных, а не пародию на него!

+
+

Рекомендации

+

4. Создавайте настоящее хранилище данных, а не пародию на него!

-
-

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

-

+

+

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

+ +

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

+

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

+
+
-
-

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

-

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

-

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

-
-
+
+

Опыт внедрения и эксплуатации

+

Внедрение

-
-

Опыт внедрения и эксплуатации

-

Эксплуатация

+
+

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

+

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

+

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

+
+
-
-

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

-

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

-

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

-
-
+
+

Опыт внедрения и эксплуатации

+

Эксплуатация

-
-

Ну вот и всё - финал!

-

Заключение

+
+

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

+

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

+

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

+
+
-
-
-

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

-

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

-
+
+

Ну вот и всё - финал!

+

Заключение

-
- Желаю всем приятной и эффективной разработки! -
+
+
+

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

+

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

+
- +
+ Желаю всем приятной и эффективной разработки! +
- + -
+ - - - +
- \ No newline at end of file + + + +