Is it possible to combine reducer & handler? about mvflow HOT 1 CLOSED

Hi there,

Is it possible to combine reducer & handler?

This is indeed one of the architectural decisions of this library that are not easy to change IMO. And those were deliberate decisions. If I could come up with a way to go around that, I would probably be losing some of the "good things" of this library I wouldn't want to give up.

I was also going to suggest having a look at orbit mvi but you already got that recommendation in the conversation. Personally, I have worked with Orbit 1.X (since then they re-wrote it and changed it a lot, and I'm not familiar with the new architecture). It's all about trade-offs. Depending on what you are doing, each of these libraries (or others) can be a better choice. In the end I doubt any particular [reasonable] choice is definitely "right" or "wrong".

In response to the author's comments I would say something along the lines of: the style of coding they are looking for makes it easier to follow a specific path of the logic - e.g. what happens when I click a button. But it doesn't help too much with understanding how that screen works. E.g. my state unexpectedly changed. Why? IMO, approaches with a single reducer and handler* allow for a wholistic understanding and the compiler / test coverage can make sure you have all possible cases addressed and tested. If you scatter handler and reducer logic in many places, then you need to know where to go to understand how things really work. It's a trade-off and there's no right answer.

I still think MVI is a very good approach for most Android apps (and outside the Android world too).

PS: I skimmed the article very quickly but devoted a few more moments to the TLDR :)

* I still allow to do composition of reducers and handlers. That is when a reducer or handler get complex enough, you could split it to different parts where each part handles a subset of the data. E.g. you have a deep hierarchy of a html website. The website contains a header, body, and footer. Each could have separate handlers and reducers. The top level just redirects things to each of the children as appropriate. I would like to make an example out of this (probably adding extra features to the library) but haven't had time in a long time.

from mvflow.