Комментарии 14
По чему не elf, а ngrx? (использовал и то и другое для компонент-стор а, elf больше лежит к сердцу. Но почему у Вас именно такой выбор? Из-за существующего глобального стора на ngrx не хотелось компонентный стор менять?)
Расскажите лучше как боретесь с кучей boilerplate при использовании NGRX?
Не понимаю этой любви к NgRx, NgRx - это мрачный мрак. Если говорить о велосипедах, свой велосипед вполне можно написать для компонентного стора и использовать его точно так же, там никакой особой магии нет.
Работал на проекте где был преимущественно глобальный стор и сейчас разрабатываю проект в который внедряю в основном компонентный стор.
Не понимаю, зачем следовать логике использовать глобальный стор для страницы чтобы потом после ее разрушения очищать стор если можно тут же использовать компонентный стор, который все это делает автоматически?
Ок, нужно вам поделиться данными, пожалуйста, отправьте экшн в глобальный стор. Хочется отслеживать состояние в Redux Devtools, пожалуйста, там есть где-то хак для этого.
После предыдущего места работы задался этим же вопросом и пришел к выводу "Действительно, а зачем глобальный стор?" Начал внедрять везде компонентный стор и пока не пожалел. А еще сигналы скоро будут - красота.
У нас еще не сложилась четкая практика, когда стоит использовать глобальный, а когда компонентный стор. Но и у глобального есть свой плюс - например, если какой-то компонент должен взаимодействовать с данными, которые затем могут переиспользоваться в других местах.
В этом случае гораздо удобнее положить эти данные в глобальный стор, обновить их там и все нужные компоненты получат их автоматически. А с компонентным придется продумывать логику передачи этих данных по цепочке компонентов.
Все верно, но в таком случае это уже не тот, кейс где вы очищаете стор после закрытия страницы. В таком случае данные вы теряете и другие ваши компоненты получат пустышки. И мы еще не говорим про lazy loading, где другие компоненты просто не смогут ничего получить пока данная страница не подгрузиться. А это, как понимаете, чревато ошибками если подгрузится не в нужной последовательности.
Для использования лучшего из двух миров я предлагаю для инкапсулированного внутри страницы состояния использовать компонентный стор, а для того, что шарится - глобальный стор (причем тот его спайс, который не инитится самой страницей т.е. не forFeature). Таким образом мы избавляемся от необходимости использовать глобальный стор для страницы и получаем возможность шарить данные через общий слайс который инитится в forRoot и таким образом не страдаем от возможных проблем с lazy loading потому что эта часть стора доступна с начала работы приложения
А в чем преимущество компонентного стора над просто внутренним стейтом компонента?
Зависит от сложности ситуации. В связи с нововведением сигналов, количество оных сокращается. Привожу примеры кейсов, какие были актуальны до их введения и что я смог оценить на собственном опыте:
1. Сбор данных селекторами без необходимости использовать combineLatest
2. Иммутабельность состояния (все сабскрайберы вкурсе что что-то обновилось)
3. Pure functions для обновления состояния (долой лишние сайдэффекты)
4. Возможность хранить и изменять вложенные структуры данных (попробуйте сделать тоже самое через сабжекты)
5. Отложенная инициализация состояния (возможность инициализации после конструктора)
6. Органичное взаимодействие с глобальным стором (те же понятия, структура и т.п.)
Если у нас просто поля, которые не связаны между собой, то можно было просто обойтись сабжектами (сейчас сигналы). Если что-то большее, то component-store прекрасно себя раскрывает и оправдывает. Опять же повторюсь, что с внедрением сигналов (реально классная вещь) будет меньше необходимости (как в случае с вычисляемыми полями), но актуальность его сохраняется
Да, хотелось бы увидеть проект, где в глобальном большом сторе была бы реальная нужда. Кроме авторизации и еще пары вещей ничего в голову не приходит.
Простота Subject’ов, удобство NGRX: что такое компонентный стор и с чем его едят