Hi, I'm new to compose. I wanted to know if there is an existing opinionated frameworks established around of compose that provides a standard structure for things like routing, state management and internationalization.

• Routing: Decompose is one of the more commonly-referenced libraries for routing in desktop apps, but personally, I’ve found that desktop apps don’t benefit from those big, heavy routing frameworks like mobile apps do. I obviously don’t know how your desktop app is structured, but “routing” typically works on full-page or full-screen locations, but desktop apps usually only have a couple of actual “screens” or windows and do more with swapping out components like editor tabs, which doesn’t work as well with those traditional routing frameworks. I would personally recommend starting without any routing library, just doing it manually, and see if you actually need this • State Management: I’ve been building just that. Ballast is an MVI library which aims to add an opinionated structure to Kotlin applications. Plus, it was initially built for Compose Desktop, unlike most MVI libraries that are very Android-focused, so you can be sure it will have great support for Desktop apps, and I just released it to a stable 1.0.0 last week! • I18n: I haven’t really found anything good here, unfortunately, but I really haven’t looked too hard. I don’t think Java/Swing really offers anything out-of-the-box for i18n like Android does, so you’re kind-of on your own for making sure your UI strings are actually localized

Thanks a lot. I was already taking a look at ballast and it look very promising. It's a shame there isn't a full fledge framework like this but maybe is not necessary after all and I'm still locked inmy web dev mindset.

Yeah, I would like to see that too. The desktop app I've been working on I've tried to build in that manner, having an opinionated application structure/hierarchy (including routing, DI and component lifecycles), but it's definitely not something I can commit to putting any serious resources into at the moment.

The todoapp example showcases both Decompose and MVIKotlin libs -. https://github.com/JetBrains/compose-jb/tree/master/examples/todoapp. You can also play with the time travel debugger - https://twitter.com/arkann1985/status/1357447358192226306

I'm Trying to make a simple router using ballast.

object RouterContract {
    data class State(
        val currentPage: PageRoute
    )

    sealed class Inputs {
        data class Navigate(val newRoute: PageRoute) : Inputs()
    }

    sealed class Events {
    }
}

class RouterInputHandler : InputHandler<RouterContract.Inputs, RouterContract.Events, RouterContract.State> {
    override suspend fun InputHandlerScope<RouterContract.Inputs, RouterContract.Events, RouterContract.State>.handleInput(
        input: RouterContract.Inputs
    ) = when (input) {
        is RouterContract.Inputs.Navigate -> {
            updateState {
                it.copy(
                    currentPage = input.newRoute
                )
            }
        }
    }

I have no idea what I'm supposed to do next. I want to be able to access this instance in all my component tree so I can change the current route.

Here’s the workflow description in the docs for a more in-depth guide, but generally-speaking, the workflow looks like this: 1) Define a Contract 2) Write the InputHandler 3) Write the EventHandler 4) Combine everything into a ViewModel 5) Inject the ViewModel to your UI and start using it So in your case, since you don’t need any Events, your next step would be creating the ViewModel. For Compose Desktop, that would mean using

BasicViewModel

as the base class, and there’s an

eventHandler { }

helper function for stubbing out the required

EventHandler

parameter of it.

class RouterViewModel(
    viewModelCoroutineScope: CoroutineScope
) : BasicViewModel<
    RouterContract.Inputs,
    RouterContract.Events,
    RouterContract.State>(
    config = BallastViewModelConfiguration.Builder()
        .forViewModel(
            initialState = RouterContract.State(),
            inputHandler = RouterInputHandler(),
            name = "Router",
        ),
    eventHandler = eventHandler { },
    coroutineScope = viewModelCoroutineScope,
)

From here, you need to create an instance of the ViewModel and observe it in the UI, as shown in the Ballast Compose Desktop example

How do I call my inputs and events inside my component? Should I pass the view model down through composition local?

You can if you’d like, but the better way is to do it the normal Compose way of “lifting state”, in this case to the root of the screen. So you’d pass the State and a

postInput

callback through your composition tree, and only at the root do the Composable functions actually get tied to the ViewModel. They’re just normal callbacks at that point. The source for the ScoreKeeper example should help you understand how it works. If you passed the whole ViewModel through CompositionLocals, the idea is the same that the ViewModel lives at the root composable for the screen, and it’s just accessed implicitly rather than explicitly. For the actual navigation, you’d create Inputs for each navigation destination, and then those Inputs fire off the Events that actually perform the navigation. Give me a minute to throw together a quick example for you

Passing props deep down the trees stroke me ass odd at first. I felt it could become unmaintainable pretty fast. Now I see that if you only have to pass state and postInput to all your components its pretty easy to maintain them. Thanks. Should I also pass a callback for postEvent?

Here’s a gist demonstrating the basic concepts, hopefully it’s helpful. I’ve omitted many of the details, such as the actual Ballast classes needed, so that the main use-cases are made more apparent. The example using DI is the way I typically handle this kind of situation, but all 3 are perfectly valid choices, so you can use the one that makes the most sense and looks the cleanest to you. Passing individual props, or callbacks for each Input type does get very cumbersome, that’s why it’s best to pass the whole

State

object around, and the callback is just for the generic Inputs superclass, even it only 1 input type if sent from a deeper Composable function. And for a

postEvent

callback, no, you don’t need that. You can’t post an Event directly to the ViewModel from “outside”, it can only be sent as part of handling an input.

Finally. This feels like a pretty good approach to routing in my app. I ended up going the CompositionLocal route. Thank you very much for all your help.

Glad to hear it, I'm happy to help!