«Почему мне нужно прикасаться к трем файлам, чтобы простая функция заработала?» Действительно, почему!
Как использовать Redux в наши дни?
Перед моей собственной реализацией управления состоянием я должен показать, насколько обычное использование избыточности является худшим в лучшую сторону.
Это худшее, что я думаю…
В этой структуре вы должны;
- Напишите «уникальные» типы действий для всех действий, если вы этого не делаете; одна отправка действия вызовет более одного случая в нескольких редьюсерах.
- Откройте 2 новых файла: «XModuleActions» и «XModuleReducer».
- Обновите файл ActionTypes с новыми типами действий.
- Обновите магазин с новым редюсером, который полностью СТАТИЧЕСКИЙ!
Это лучше, чем предыдущее с модульным шаблоном, но у него есть недостатки…
При использовании этого типа вы должны;
- Обновите каждый файл редукса для добавления нового действия.
- Создайте новую папку redux с 3 файлами для каждого нового модуля. Это приводит к плохому опыту разработки в больших проектах, которые состоят из сотен модулей с неограниченными уровнями данных, и это неуправляемо.
- убедиться, что типы действий снова уникальны?
- редукторы STATIC снова
В PowerDev у нас есть приложения, управляемые данными, с бесчисленными модулями, картами и безграничными диаграммами для визуализации данных.
Давайте помечтаем создать по 3 файла для каждого из них и обновить магазин во время разработки! Какая огромная трата времени, сотни повторяющихся кодов и плохая реализация простого управления состоянием?
Есть еще одна большая проблема…
Например, в нашем приложении есть настраиваемая панель мониторинга, которая создается по запросу пользователя с настраиваемыми диаграммами.
Должен ли я держать все эти редукторы на корневом уровне?
В приборной панели могут быть модули, к которым у пользователя нет доступа.
Согласно этим;
- Динамические строительные леса редуктора или создание по требованию зависят от ваших потребностей.
- Все редукторы не должны добавляться в Store статически.
- Любой модуль должен иметь возможность внедрить свой уровень данных и удалить себя из хранилища, когда это необходимо.
- Компоненты React должны иметь возможность лениво загружать свой избыточный слой.
Выполнение
Функции Store, injectReducer и removeReducer.
Для лучшего понимания отметьте Closures и IIFE.
Генератор динамических срезов (редукторов) с RTK
Lazy Reducer Provider для загрузки редьюсера (для клиентских модулей)
Наконец, генерация всего редукса в одном файле
Структура файла
Модуль/redux.ts
Создание действий и редьюсера в одном файле простым вызовом CreateDynamicSlice
Внедрение и использование редьюсера и действий
Заключение
Мне не нужно:
- Напишите глупые действия или типы действий для простого обновления состояния
- Обновите и создайте так много файлов для управления состоянием
- Загрузите каждый редьюсер в проекте с инициализацией приложения
- Используйте диспетчеризацию с useDispatch для простого изменения состояния
Теперь я могу:
- Динамически обновлять любую часть состояния одним действием
- Ленивый редуктор нагрузки с модулем (при необходимости)
- Все в одном слое данных файла
- Легко использовать!
