Hi. Anyone using ballast in a KMM project. I’m new to iOS development and I wanted to know if ballast was a good fit here, or even if it was a good idea bringing the common code to the MVI framework in the first place.

Hey everyone, with the recent release of Kotlin 1.8, I am starting prep on a new major version of Ballast to go along with it. With a major release of Ballast comes the opportunity to improve its API, and I’d love to know if there are any particular features of APIs that you would like to see changed. I’ve got my own list of potential changes from discussions here, but please leave a comment here or an issue on the repo if there’s something else you’d like to see improved.

When I've exceeded 20 inputs for the view model, my InputHandler class became too large to manage comfortably. It's not trivial to partition the class into smaller pieces. I've tried to split my view model, but it was a dead end (my state class is not large and is really shared by most of those inputs).

Any code examples on how to handle side effects using ballast e.g. making calls to an API? Also, I noticed that there's an example section in the ballast docs but I couldn't find any links to the repository. 🤷‍♂️🏾

Documentation for KVision is now added to the docs site • KVision platform page • KVision TODOMVC

Hi. I only found out about Ballast last night and will give it a go today. The Ballast seems very nice, I like the readability it provides. In my KMM project, Android and iOS, I share UI in the

commonMain

using the Jetbrains Compose. Do you have any recommendations for using Ballast in this use case? Expect/Actuals for ViewModels?

Navigation. Are we supposed to have one big router for handling the whole navigation in the app or multiple small routers?

I migrated my app from MVIKotin and Decomposed to Ballast, all in a few hours, and I'm quite impressed. Building components feels just right. It is easy to decide where to put stuff. For now, i only have like 4 of them. Router, Login, Dashboard, Product detail. Only have a simple route from Login to Dashboard, but today end of the day, i will add a few more components and will have some questions about navigation with multiple arguments, probably. Do you handle multiple nav args in any of your samples? Is there any way of accessing the router further the back stack we get? Or the only way is passing for example

onGoBack: () -> Unit

Hey everyone, I’m looking to make some improvements to the SavedStateAdapter such that you could send multiple Inputs and/or Events after the State has been restored, but I’m not sure the best DSL to use for this. I’d love to get some feedback on the potential ways this could be implemented, and votes on which option you’d prefer. My suggestions are in the 🧵, but feel free to make other suggestions.

Hi. I've got an issue with my text field adding extra characters. Originally posted here but moved it to GH. https://github.com/copper-leaf/ballast/issues/40

BTW i'm introducing ballast at work as a state management library in Android and iOS KMM project with shared UI Compose-JB 🙂 We won't be using it in the current production app (yet) because they have already invested a lot of time in React Native 😕 , but we will be using it for our internal testing app, which may replace the prod app in the future (hopefully). We still need to do a bit of testing, with Compose-jb mainly.

The above issue was the only issue I noticed so far. I'm still working on my own KMM project on the side. Ktor backend, Android, iOS, Desktop and Web. i share my components/features with all targets, thanks to Ballast 🙂

In my component, usually, the Inputs file gets quite long. I already use separate use cases to make it shorter. What's your recommended way of keeping logic in Ballast components?

Just thought that Inputs could take a function as a parameter, then I could keep logic in the VM, and inputs could handle... Inputs only. Right now, all VMs have no body.

current hierarchy of my app starts with: • Root - I use for initialising Koin and passing RootContent in targets • Router - does routing ofc and runs scope in VM for monitoring Auth state. if logged out it tells router to go back to login page • Login page • rest of the app Is it ok to keep the observe user state logic in the Router's VM, or should I move it up one level? Currently the root is not a ballast component.

I give it a try

Make's sense because there is no way of adding extra inputs to the router just to do that, and i dont we should anyway. Router should do routing only.

Creating infinite flow. I get

20:15:18.730  W  BallastException(_cause=java.lang.IllegalStateException: This InputHandlerScope has already been closed, handled=true, latestState=State(isUserSignedIn=false), inputSequence=[src.txconnected.mobox.shared_ui.component.root.RootContract$Inputs$ObserveUserState@ce9ec24])

Here is my input:

RootContract.Inputs.ObserveUserState -> observeFlows(
            "observeUserState",
            flow {
                while (true) {
                    postInput(RootContract.Inputs.CheckUserState)
                }
            }
        )

        RootContract.Inputs.CheckUserState -> postInput(
            RootContract.Inputs.ChangeUserSignInState(
                SDK.sessionManager.isLoggedIn
            )
        )

        is RootContract.Inputs.ChangeUserSignInState -> updateState { 
            it.copy(isUserSignedIn = input.newState) 
        }
    }

And i start it in the RootContent:

internal fun RootContent(
) {
    val coroutineScope = rememberCoroutineScope()
    val snackbarHostState = remember { SnackbarHostState() }
    val vm = remember(coroutineScope) {
        RootViewModel(
            viewModelCoroutineScope = coroutineScope,
            displayErrorMessage = { snackbarHostState.showSnackbar(it) },
        )
    }
    val state by vm.observeStates().collectAsState()
    vm.trySend(RootContract.Inputs.ObserveUserState)
    RouterContent(state.isUserSignedIn)
}

In router gets false will got back to Login page:

internal fun RouterContent(isSignedIn: Boolean) {
    val scope = rememberCoroutineScope()
    val router: Router<RouterScreens> = remember(scope) {
            RouterViewModel(scope,)
        }
    val routerState: Backstack<RouterScreens> by router.observeStates().collectAsState()

    if (!isSignedIn) {
        router.trySend(RouterContract.Inputs.ReplaceTopDestination(
            RouterScreens.Login.matcher.routeFormat
        ))
    }

I just migrated from OrbitMVI to Ballast. In 3mins. I like the "it just works" nature. Kudos. I'm moving onto navigation with Ballast. If I'm not mistaken, it's built ontop on the redo and undo lib by the same author. My question is do I still need compose navigation with Ballast navigation? If yes does ballast handle backstack??

Noticed that restoring the state in SavedStateAdapter is visibly slow. When the screen loads I can see text fields populating and tabs switching. Works fine when setting state values from preferences.

CleanShot 2023-02-13 at 23.12.58.mp4

Hi. I used Ballast (Core & Navigation) in this project and I would like your feedback regarding its usage including any criticisms and suggestions. Thanks.

hey all, when i try to begin writing

class RouterViewModel(
    viewModelCoroutineScope: CoroutineScope
) : BasicRouter<AppRoutes>(config = BallastViewModelConfiguration.Builder())

there's an error on BasicRouter because the <init> is private on BasicViewModel. additionally it claims to not find the config field. Clearly this is strange as BasicViewModel has a public secondary constructor defined right there where i can see it. am on ballast 2.3.3

anyone consider making some dsl wrapper for the builders used in ballast? feels funny to see Builder patterns about when i would expect something more like

config = viewModelConfig {
    withRouter(...)
}

just as an example

here i am with more questions. just want to be cautious, i am planning to implement a provider for the coroutine scope with koin like so

single { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + SupervisorJob()) }

that should make it easy to similarly provide ballast components with koin, which require this coroutine scope? im worrying because it seems like compose scope is great for managing the lifecycle of components like viewmodels already (leaving the composition discards the instance), so maybe koin is overkill for this

another q! im trying to implement my first viewModel, and linking it up with navigation isnt so clear. my instinct is to pass the router to the EventHandler, but that means passing it through a bunch of constructors and params which doesnt feel good. another thing is an event handler having access to the whole router means you lose control of what navigation events the screen has access to. the example on the website addresses the second point, and suggests passing the navigation event through a Screen callback

PostListScreen(
                        sort = sort,
                        onPostSelected = { postId: Long ->
                            // The user selected a post within the PostListScreen. Generate a URL which will match
                            // to the PostDetails route, by using its directions to ensure the right parameters are
                            // provided in the URL
                            router.trySend(
                                RouterContract.Inputs.GoToDestination(
                                    AppScreen.PostDetails
                                        .directions()
                                        .pathParameter("postId", postId.toString())
                                        .build()
                                )
                            )
                        },
                    )

and that could work, in fact i do something very similar on android, but it doesnt feel idiomatic to ballast? for example if we wanted to navigate not directly from a ui click (and in fact, from what i understand of ballast, it would be weird to drive anything from the ui except an

Input

anyway), but instead drive a navigation event from business logic, we would still have to pass this navigation lambda to the event handler manually. should i provide the router through a

single {}

and inject it into the event handler? maybe with an interface that only exposes navigation routes available on this screen?

hi, just occurred to me, is the coroutine we pass to ballast ViewModels used solely for lifecycle control? I have my Router set up to be injected by Koin as a single, but for this reason its not really possible to pass it the coroutineScope remembered at the app Composable level, and instead i just have a factory method for the scope. facing this question again for the repositories so i figure now's the time to get this right for me. @Andromadus Naruto’s repo was an interesting example, where the "applicationScope" provided is thus

val AppScope = CoroutineScope(window.asCoroutineDispatcher())

which is a browser thing, but it also makes me wonder what would happen if this coroutine was cancelled for any reason (at a guess, the window as coroutine dispatcher prevents that from happening?)

Is there a way to explicitly cancel a side job? I could create a new one that does nothing with the same key but that's a bit ugly.

hey hi, the project im working on is an incremental game (think cookie clicker) so theres going to be a fair amount of time based logic, like production of resources per second on an update loop. the way ballast has me set up im struggling to conceptualise any kind of classic game loop where i have delta time between updates, because there are so many suspend functions and indirect Event dispatching, potentially across multiple repos, it would for example be hard for me to figure out when a state-wide update has been successfully completed. any idea how to tame this kind of logic?