Comments 10
Как по мне, то либа более многословная в плане создания экшнов по сравнению с flux-action-class.
Если же говорить о редьюсерах, то ее функционал ничем не отличается от кейса "Выбор редьюсера из объекта по ключу" разобранного в этой статье. В начале главы "Редьюсеры на основе классов" я расписал те преимущества, которые я вижу для себя. Безусловно это очень субъективный набор. Для себя все же пока остановился на классовых редьюсерах в силу читаемости и, как следствие, поддерживаемости.
Если же говорить о редьюсерах, то ее функционал ничем не отличается от кейса «Выбор редьюсера из объекта по ключу» разобранного в этой статье.
Это не так. В показанном выборе редьюсера из объекта по ключу очень много недостатков которые отсутствуют в unionize подходе:
— unionize поддерживает не только удобное объявление экшенов но и удобную дальнейшую работу с ними (матчинг, фильтеринг и тд)
— Добавить TypeScript типизацию указанному способу так просто не получится потому что объект «оторван» от объявления самих экшенов в которых указаны типы пэйлоадов. Это мега большой недостаток. Нетипизированный JavaScript в наше время вообще вредно использовать для проектов сложнее todo app или hello world.
— Нужно отдельно где-то объявлять и потом отдельно импортировать константы на экшены. Это ведет к неоправданному росту бойлерплейта. В сочетании с отсутствием типизации очень легко сделать ошибку сопоставляя ридьюсер с определенным экшеном. Нетипизированный JavaScript в наше время вообще вредно использовать для проектов сложнее todo app или hello world.
— В случае unionize при матчинге нужно либо опиcать обработчики для всех объявленный экшенов или добавить default обработчик и это подкреплено на уровне TypeScript. Получается что забыть объявить обработчик для экшена не так просто и это хорошо.
Перед выбором unionize я просмотрел множество самых разных библиотек хелперов, хотел свое написать, но unionize оказалась достатоной для моих нужд штукой. Там есть некоторые недостатки, но они решаемы (как например добавление префикса для экшенов).
Да, вы правы. Плюсанул. unionize лучше выбора по ключу как минимум в плане типизации.
В случае классов с декораторами мы можем добиться не худшей типизации если на один экшн приходится один редьюсер и мы используем классы для экшнов. В статье я не стал описывать этот функционал, дабы не ее совсем не раздуло, но в библиотеке он есть.
Посмотрите на пример. В частности, на метод addEnergy. Экшн по которому выолнится редьюсер заинферится из типа.
О, новая выставка велосипедов!
У меня вот так еще с тех времен, когда Angular был только 2 и ngrx еще не был platform.
Типичный reducer.ts при этом выглядит как-то так:
export const reducer = new ReducersMap<State, Actions.All>(initialState)
.when(Actions.FOO, (state: State, action: Actions.FooAction) => ({ ... })
...
.reducer;Велики только после покраски! Налетай!
Ваш вариант лучше простой мапы экшнов описанной в главе "Выбор редьюсера из объекта по ключу" хотя бы тем, что позволяет биндить один и тот же редьюсер на массив экшн типов, но мне кажется, что он все же проигрывает в читаемости классам.
Плюс в reducer-class из коробки immer, поддержка разных экшн криэйторов, дабы не передавать сам тип, обработка кейса, когда одному типу соответствует несколько редьюсеров.
Согласен. Я это по-быстрому написал за 10 минут, потому что ненавижу switch-и :-) На практике оказалось достаточно удобно, чтобы не задумываться о замене.
Год назад как-то наткнулся на вот эту статью:
https://medium.com/developers-writing/a-class-based-approach-to-writing-reducers-in-redux-ngrx-4a8ec5f97b1
там подход очень похож на ваш.
Оверинжинирг 80 уровня или редьсюеры: путь от switch-case до классов