uber / RIBs

Uber's cross-platform mobile architecture framework.
https://eng.uber.com/tag/ribs/
Apache License 2.0
7.73k stars 904 forks source link

To keep the state in Presenter or Interactor for click events? #411

Open ericntd opened 3 years ago

ericntd commented 3 years ago

I'd prefer to keep things stateless if possible A Stream is perfect for that but too much work So keeping the state for click events But can't make up my mind between the Interactor and the Presenter Any recommendations?

A typical Interactor:

override fun didBecomeActive() {
        super.didBecomeActive()
        getDataAsync()
               .subscribe { theData ->
                       // to keep theData as state here or not?
                       presenter.present(theData) // or inside the Presenter? 🤔 
               }
}

// upon user click, we need to theData again
fun onClick(theData: TheDataType) {
}
andreasnomikos commented 3 years ago

Actually to better utilize unidirectional data flow you should not make the presenter api imperative.

Loading your asyncData to a state store like https://reduxkotlin.org/ is a better option then you can monitor that into the presenter usually after transforming it first to a viewmodel. If you follow the clean architecture paradigm this looks as such

Usecases load DTOs -> Interactor stores Entities (ReduxStore) -> Presenter renders ViewModels

ericntd commented 3 years ago

My previous teams migrated away from event bus into Reactive programming (with RxJava) for good reasons. So redux is a thanks but no thanks

J909 commented 3 years ago

In case getDataAsync() were to cache the last emission e.g. with replay(1), you could getDataAsync().take(1) in your onClick() callback.