s3rius
06/20/2024, 9:44 AMapp <-- ui <-- core
\--------/
• app
is basically a boostrapper for the application, setting up DI, UI entry point etc,
• ui
has all composables, theming, etc
• core
has everything else; "view models", business logic, etc.
ui
depends on core
because core
defines a ton of data classes to be used inside the ui
.
The transition worked pretty well with the exception of one thing: I have a few composables that use custom state classes (similar to TextFieldState, ScrollState). These state classes are sometimes hoisted all the way up into the ViewModel (so they live as long as they VM does). But since these state classes are part of the UI, they now sit inside ui
. To use them inside ViewModels it would require a dependency from ui --> core
which doesn't work since I already have ui <-- core
.
I'm at a bit of a loss as to how to resolve this issue without going ham on modules.
• I could keep the state classes inside core
. That rips apart the composable and associated classes, but works with fairly minimal trouble.
• I could pull the composable+state into separate modules but creates a set of tiny modules for a bunch of UI elements.
• I could flip around the dependency between ui and core but I think that would require a lot of extra data classes and mapping between ui and core domains. That's a lot of change at once.
Since the project is already quite large, I don't want to make massive, disruptive changes at once but rather work step-by-step towards a modularized project. So I'm a bit apprehensive particularly about option 3.
Is there any general guidance or good example of practical modularization? Particularly for existing code bases? I know there are a few Github projects out there but it seems to me many of them go completely overboard with a mountain of tiny modules.