Комментарии 6
Каждая такая статья показывает как правильно нарезать слайсы, помогите найти объяснение почему их надо нарезать?
А что значит нарезать? Создавать отдельные слайсы, а не держать все в одном?
Такой вариант подходит, если необходимо создать несколько идентичных по поведению слайсов, но со своими экземплярами стейта и экшенов.
Зачем это может потребоваться?
Да и в целом, зачем создавать слайсы?
Например, для разных ролей пользователя есть несколько одинаковых разделов с фильтрами и поиском. Если мы хотим чтобы эта информация не терялась при переходах между страницами, то нам нужен для каждой страницы свой стейт и свои экшены, чтобы они не пересекались.
Слайсы (любой стейт менеджер) используют чтобы:
1)сохранять состояние между страницами,
2)не писать логику сложных больших компоненты на useEffect,
3)не обмазывать все мемоизацией,
4) стейт в реакте должен лежать в родителе и любое его изменение = ререндер,
5) не прокидывать кучу пропсов с родительского компонента в дочерние из-за п.4
Просто перестаньте страдать и использовать редакс.
Спасибо за статью! Попал на проект с redux-toolkit и как раз сейчас исследуем, как лучше переиспользовать код слайсов. В интернете мало информации об этом.
Будут ли в будущем статье на перечисленные темы? Толковые статьи по redux-toolkit полезны тем, у кого проект на нем.
Прокомментирую описанные подходы и добавлю еще один.
Первый вариант выглядит тем, к чему стоит стремиться. В отличие от всех остальных подходов в нем происходит разделение большого слайса на более мелкие слайсы, отвечающие за разный функционал даже в пределах одной страницы. Это соответствует SRP принципу из SOLID.
Правда на redux-toolkit придется подключать больше слайсов для каждой страницы, что довольно неудобно.
Еще могут быть проблемы, если вдруг потребуется хранить и работать с одними и теми же данными в нескольких слайсах.Вариант 2, предлагаемый также в официальной документации, это создание обертки с переиспольезуемым кодом и смешивание его в одном объекте (может под капотом и не в одном, не разбирался) с передаваемым кодом. Напоминает наследование. То есть самописная вариация наследования для redux-toolkit c большими сложностями типизации редьюсеров.
Данный вариант не подойдет, если в одном слайсе планируется разместить большое количество функционала, т.к. тем самым он превратится в антипаттерн God Object, с которым будет трудно работать. Так же в этоv подходе можно случайно перезаписать другие редьюсеры в создаваемом слайсе.
Вариант 3 (Ваш вариант) - вынесение переиспользуемого функционала в отдельный объект. Далее экземпляр этого объект используется внутри других слайсов, в которых пишутся редьюсеры, обращающиеся к этому объекту. Вроде бы это паттерн стратегия.
В этом варианте придеться писать дополнительный код в слайсах - редьюсеры, обращающиеся к внутреннему объекту.
Вынесение переиспользуемого кода в функции-миксины, которые можно применять при создании слайсов.
Меньше кода, чем в варианте 3, но те же проблемы (за исключением проблем с типизацией), что и в варианте 2, т.к. в обоих вариантах происходит смешивание функционала.
Для переиспользования кода еще используется паттерн декоратор. Но не уверен, что он применим к redux-toolkit слайсам.
Redux-toolkit и переиспользование кода