How would you handle inheritance and MVI, output State model in particular? Nesting of parent state?...

# android-architecture

[ursus]

How would you handle inheritance and MVI, output State model in particular? Nesting of parent state?

State(.. my vals, val parentState : ParentState) ? Im not a huge fan of this as concept of ParentState being exposed outside.. maybe flatten it via interface + by delegation?

[sngrekov]

Use composition instead of inheritance

[ursus]

Havent I in the sample?

[sngrekov]

Why does child state contains parent's? To me it seems like mistake in modelling phase

[ursus]

Well, code sharing, basically its this
BaseChatViewModel
- ThreadChatViewModel
- RootChatViewModel

[ursus]

thats kind of the issue, that mvi says there should be only 1 State model, and how to make this work with inheritance, or composition for that matter, there is quite a lot of stuff share in BaseChatViewModel, and ifself has State, so how to compose it with ChatViewModel state for examplr

[sngrekov]

A usual recommendation is to drop inheritance, since it dictating very rigid structure to your models. If you have reusable components in your state, the usual recommendation is to break them into separate models and compose them into concrete state, and handle interactions with it with functions (thats where the power of pureness of reduce function comes into play)
Side note - why do you have xxViewModel classes? MVI doesn't have such component, you probably intermixing approaches..

[ursus]

Yea its a hybrid of mvvm and mvi, where there is only one State stream out, but thats just semantics

[ursus]

so your root level reducer would just proxy actions to these reusable reducers?

[sngrekov]

> so your root level reducer would just proxy actions to these reusable reducers?
Correct

[ursus]

Where do the Actions live then? Are they owned by each subreducer, and root reducer duplicates them and they get mapped? or is there some common enum of them

[sngrekov]

Where do the Actions live then?

Why do they need to live somewhere? Emit the Action (by user input or by environment) and handle it in component (reducer or whatever)

[ursus]

You dont have them as sealed class?