Is it possible to use Decompose and MVIKotlin?

[CXwudi]

Hi,

Thanks for making such a great Kotlin frontend library. I am wondering is it possible to integrate Decompose and MVIKotlin for shared navigation and business logic modules?

The idea is that, I use Decompose and MVIKotlin to share as much code as possible all the way up to the navigation part and build the navigation tree as the shared module

Then I could have Compose UI for Desktop, Android and iOS, while having Kobweb for web

So I am wondering is it possible?

[bitspittle]

Sorry I didn't respond until now. It's very busy as we are getting ready for KotlinConf, so apologies for dropping this on the floor.

I am not really familiar with Decompose or MVIKotlin, so I don't really think I can offer any great advice here. I started to look into both but then got distracted when I first saw your question.

My rough guess is that Decompose will be a fight. It sounds like it's trying to solve what Kobweb core is solving. MVIKotlin sounds like it is architecture agnostic so I guess it should be possible?

Note that we tried to architect Kobweb into components so that even if you don't want to use our main stuff, you can use our libraries at least. Specifically:

Silk widgets w/o Kobweb:
https://github.com/varabyte/kobweb/tree/main/frontend/silk-widgets/README.md

Silk classes w/o widgest:
https://github.com/varabyte/kobweb/blob/main/frontend/silk-foundation

The layer that adds Android-like components into Compose HTML
https://github.com/varabyte/kobweb/tree/main/frontend/kobweb-compose (where Modifier lives) without Kobweb.

Additional goodies for Compose HTML:
One can also use https://github.com/varabyte/kobweb/tree/main/frontend/compose-html-ext and/or

Additional goodies for lower level browser APIs:
https://github.com/varabyte/kobweb/tree/main/frontend/browser-ext

[CXwudi]

Thanks for ur reply and all the links. I guess using silk-wedget library as standalone would be a feasible way to use kobweb UI on top of Decompose navigation

[bitspittle]

Just note that silk-widgets in currently in the weakest form it will ever be. I have only implemented probably 5-10% of what I want to have done for 1.0. Maybe these will start to fill out by the end of this year.

Silk Foundation, the layer that introduces concepts like CssStyle, is still very useful! But it's much nicer when you have the Kobweb machinery generating the boilerplate code for you; by using only Silk Widgets, you are opting out of that.

[bitspittle]

BTW, it occurred to me I should point you to optional catch-all routes, as a possible approach to consider, if you want to use Kobweb but opt-out of its routing / navigation capabilities:

https://kobweb.varabyte.com/docs/concepts/foundation/routing#optional-catch-all-routes

In other words, if you define this page (with the {...path?} syntax):

// com/mysite/pages/Index.kt

@Page("{...path?}")
@Composable
fun CatchAllPage() {
    val ctx = rememberPageContext()
    val url = ctx.route.params.getValue("path")
    /* ... */
}

then ANY route you visit will be converted into a string and passed into that single composable. Maybe at that point you could take that string and delegate to Decompose?

Not sure as I haven't tried it, but it is a potential option.

[CXwudi]

Ohh the catch-all route is interesting, because recently Decompose introduced an experimental Web Navigation API. Basically it allows user to make a mapping between each segment of the path into a each node in the Decompose navigation tree.

Now if Decompose can support receiving the path from ctx.route.params.getValue("path") it would be a great way to integrate, although I am not sure how and if it is possible to achieve from this way, I honestly haven't looked deep into the experimental Web Navigation API yet.

Anyway thanks for pointing out this interesting direction