middlewares and reducers notifications

[pablodeafsapps]

Hi! I happen to be developing an app using this library (thanks for this, btw!) and, after a thorough debugging process, I have spotted that all my reducers and middlewares get called on every new Action dispatch.

Thus, regardless which Activity or Fragment I am, any store.dispatch(MyAction()) triggers all reducer and middleware instances (I guess this means that I could even define all reducers and middlewares in the same file). Apart from finding this a bit inefficient, I wonder whether this is the only way to do it or there is a smarter approach.

Thanks and regards,

[kmmraj]

If you see the typical redux cycle, it has both reducers and middleware will be triggered for every action dispatch. This is by design. Please refer - https://blog.gisspan.com/2017/02/Redux-Vs-MVC,-Why-and-How.html

[pablodeafsapps]

Thanks for the link, I find it very illustrative. However, the diagram shows a single View subscribed to a particular state and getting update by the middlewares + reducers chain. My question related to many views co-existing in an application (1 Activity and 2 Fragment instances, for example), and my proposal was to make reducers and middlewares receive Actions dispatched from the related View only. I guess I just have to suck it up... :|.

I doubt whether this also happens in ReSwift. Do you happen to know this?

[jitinsharma]

@pablodeafsapps
ReSwift has the same behaviour.
Existing architecture doesn't have any extensions to provide ids to reducer/middleware which could then be tracked down when dispatching actions specific to them but it looks like food for thought!

[pablodeafsapps]

Thanks for your comments, @jitinsharma
After been working with ReKotlin for almost a month, I'd like to say I think it is a great piece of software. I mean, my comment above could maybe make it better, but it probably would lead us to have too many subscriptions in too many items.

Reached this point, there is only one main drawback I am facing right now: my Activity/Fragment files (i.e. UI) are growing way too much. Coming from MVP and VIPER, where the presenter handles any action performed over the View, it looks a bit untidy to me having Activity instances so full of code. I guess there are best practices on how to use ReKotlin, but some tips would be appreciated... ;)

[monday8am]

hi @pablodeafsapps , I'm using ReKotlin right now and I have used ReSwift before. It is true that not all apps are suitable for this pattern but it is something you have to decide, together with you preferences about how to write code (more or less functional) . I wrote a post about it recently, hope it helps a bit.

Using Reswift and iOS you don't have to think too much because the state is kept in memory the whole time, but in Android you should take in account activities lifecycle, etc. IMO a single activity app is a better setup but again, it is another decision you'll have to take ;)

[jitinsharma]

@pablodeafsapps
IMO a presenter could still be present with redux(pardon my limited knowledge on MVP).
It's not necessary StoreSubscriber to be implemented by Activity/Fragment. A Presenter could implement this allowing you to clean up code on Activity/Fragment.

[pablodeafsapps]

Not sure about Presenter, @jitinsharma. I mean, it will clean up my code by adding a new "layer" to my architecture, with not a "real" Presenter though. A Presenter coordinates the whole action in MVP, getting updates from the View and querying the Model when needed. Since ReKotlin is based on unidirectional flow architectures, I guess this Presenter-ish will not make sense.

Again, this is a guess, and even so I still like your idea of a layer/class abstracting state subscriptions, so they get removed from Activity/Fragment instances.

[kmmraj]

@pablodeafsapps Can we close this issue?

[kaustavjaiswal]

@pablodeafsapps Closing this issue for now, as no further action is needed, if anyone comes up with a way to solve this, feel free to raise a PR