и seatsRemoveAction, которые должны вызывать свои диспатчи(на тугл и ремув и менять состояние сита в сторе)
Параллельно с этим, вызывается функция selectSeat, которая делает проверку на рулы, после чего, если она существует, то пихает в Data обьект, чтобы в будущем, при следующем вызове, если рулы проходят, отправить все одним батчем в реквесте.
Почему я вижу это в провайдере, так это потому что мне не надо будет вызывать еще один экшон для всех этих действий, а делать это в редьюсере не самая красивая вещь, как по мне( если делать это при подписки на action type). поэтому у меня и появился вопрос как лучше сделать.
Вызов еще одного экшена- это вызов еще одного диспатча, который потом позовет проход всех редьюсеров еще раз. Это быстро, я не спорю. но зачем?
Хочешь изолированные хранилища — возьми mobx У редакса концепция такая, почитай про SSOT. Можешь и в сервис вынести — тебе будет проще, а остальным не оч. «Почему всееееее данные хранятся в редаксе, а вот эти вот в отдельном сервисе? тааааак, падажжи, не может же это быть написано ПРОСТО ТАК? хм... аааа, да, это написано просто из-за «красоты», спасибо тебе автор за бесценные часы попыток понять»
все звучит логично, но тригерить экшоны для этого?Просто как человеку, который раньше писал на шарпе по ООП, а после пришел первым делам в ангулар, то мне видится, что, для сохранения хоть как-то логики проверки этих рулов- изолировать. если же мы ее пихаем прямо в экшон, то мы его показываем. из серии: вот посмотри, из-за этой проверки ты не можешь пройти дальше. и вот тут возьми эти данные, чтобы отправить реквест. Я ЗНАЮ, что такого рода проверки должны быть на сервере, но тут так не получится( легаси и не разрешат менять. Слишком опасный и важный кусок кода). Или все же это окей, чтобы в открытую делать такого рода проверки?
Паттерн flux плохо сочетается с шарповым ООП. Модели мышления разные
я понял, спасибо 🙂 значит сделаю еще несколько редьюсеров с данными
Обсуждают сегодня