Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ViewModel refactor - common ViewModel by composition #231

Closed
wants to merge 3 commits into from

Conversation

russhwolf
Copy link
Contributor

Moves VM logic to BreedCommonViewModel, which is wrapped in an androidx.lifecycle.ViewModel on Android and a custom CallbackViewModel class on iOS. The BreedCallbackViewModel is wired into ObservableBreedModel in Swift which uses some different internals but keeps its existing interface.


val breedStateFlow: StateFlow<DataState<ItemDataSummary>> = _breedStateFlow
val breeds = commonViewModel.breeds
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe get() accessor vs keeping a state reference here? Seems like a simple passthrough.

private val _breedStateFlow: MutableStateFlow<DataState<ItemDataSummary>> = MutableStateFlow(
DataState(loading = true)
)
private val commonViewModel = BreedCommonViewModel(breedRepository, log, viewModelScope)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering, do we need to hide the commonViewModel and duplicate it's signature here? Is there any reason not to have this classes responsibility be just creating the common one and making it accessible to callers? I think the main reason would be confusion at the call site breedViewModel.commonViewModel.refreshBreeds() is obviously pretty ugly. But with some improved naming, might be worth it to avoid maintaining the duplicated signatures?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In KaMPKit we don't, which is a refactor on my (undocumented, oops) todo list before merging this. In general though, you might want this separation if your platforms are not perfectly in-sync because it gives you a place to put android-specific stuff. It's also a place you can convert to LiveData or RxJava or anything else platform-specific you might be using in existing Android code.

private val clock: Clock
) {

private val log = log.withTag("BreedModel")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't need this anymore as the tag is added here, right?

@@ -63,6 +64,16 @@ private val coreModule = module {
// See https://github.com/touchlab/Kermit
val baseLogger = Logger(config = StaticConfig(logWriterList = listOf(platformLogWriter())), "KampKit")
factory { (tag: String?) -> if (tag != null) baseLogger.withTag(tag) else baseLogger }

single {
BreedRepository(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be great for readability to have named arguments, especially since this is a widely referenced sample project.

@russhwolf russhwolf mentioned this pull request Mar 9, 2022
@kpgalligan
Copy link
Contributor

PR #238 is a merge of the view model concept PRs. Closing this one.

@kpgalligan kpgalligan closed this Mar 18, 2022
@kpgalligan kpgalligan deleted the rw/viewmodel-composition branch March 20, 2022 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants