We are considering approaching with KMP for mobile...

# compose

[neworldlt]

We are considering approaching with KMP for mobile and web UI development. Initially we are planning to use compose-web, but eventually migrate to compose-html (we have design system and working prototype). I am wondering, how should I structure the code to have both compose-html and compose-web support and not shoot our foot? Naturally sourceSet structure looks like as following, but I am wondering if it is a future-proof approach?

Also, would it be even possible to mix html and web in he same product (the same namespace)? Something like having ComposeViewportHtml and ComposeViewportSkia (edited)

[andylamax]

This looks fine. Allows you to share as much as you can accross skia based targets

[neworldlt]

I think so. But the problem is JS target, since I can have only one JS target.

[neworldlt]

Refined diagram. Ligh-blue color are targets which are supposed to provide libraries

[andylamax]

You can have wasm under skia, and leave JS for for compose HTML

[neworldlt]

Nice, idea, something to consider. But I fear I could have some unexpected hard limitations in the future

[Ivan Matkov]

I'd suggest considering multi module structure instead of source sets in this case.

[neworldlt]

That makes sense. But there is another problem, what I can do about having both Compose-web and Compose-html in the same product? For example, letting gradually migrating from skia to html and vice-versa.

One idea pops in my mind it to have single JS target which can switch between rendering engines, like:

@Composable
fun Card() {
  if (LocalJSRenderingEngine.current.engine == HTML) {
    HTMLCard()
  } else {
    SkiaCard()
  }
}

But what could wrong and what performance impact could be?

[Ivan Matkov]

I don't think that you can do it in this way. Because despite of being "@Composable" these functions requires different entry point/appliers/etc. "SkiaCard" requires creating canvas via "ComposeViewport" for example and cannot be used from HTML's root/entry point.

[neworldlt]

Since I don't need mix canvas and html inside same viewport, I thing it could work with wrapper of ComposeViewport and related Viewport for html.