Are Compose Multiplatform Resources, part of the 1...

# compose-web

[David Herman]

Are Compose Multiplatform Resources, part of the 1.6.0 release, something that can also work with Compose HTML? (https://blog.jetbrains.com/kotlin/2024/02/compose-multiplatform-1-6-0-release/)

[Robert Jaros]

It does work, but it currently has dependency on skiko and loads a lot of unused code. See my question here: https://kotlinlang.slack.com/archives/C01F2HV7868/p1706131400061739

[Robert Jaros]

I've opened an issue: https://github.com/JetBrains/compose-multiplatform/issues/4495

[Arjan van Wieringen]

Why would you need this for Compose HTML? Everything already works out of the box, since you can just access your resources from the resources folder in your client Kotlin/JS code. At least, we haven't seen a reason we would need it in our web app.

[Robert Jaros]

I would like to use strings to support different languages.

[Robert Jaros]

And I personally work with common code, so I can't just access these resources in my code.

[Arjan van Wieringen]

Makes sense. But we also have those use-cases and we just made some simple helpers. We have po files in common code and read them in different places.

[Robert Jaros]

Can you share your solution?

[Arjan van Wieringen]

Well, it is proprietary code (commercial app).

Basically most problems can just be solved by simple interfaces and implementations and use of DI.

We use DI heavily (Kodein) and have:
• common di module (with all the common code)
• platform specific modules (which implement platform specific interface implementations)
But, typically it goes like this:
• define or use a common format to work with the resource; Like a string, or maybe a data class hierarchy for something more complicated.
• define a loader interface to load a certain resource type to a common format, so a PO file to a string
• implement the loader interface in the lowest possible target (Common would be great); but for the PO one can imagine something like a URLLoader which fetches it from an URL
• bind the implementation in a DI container to the interface
The in common code we might have a TranslationService which injects a TranslationLoader (which is provided by the platform). This translation service can be used in any code. And it allows us to switch out implementations in tests or other places.

The PO files are just in the common code resources dir and we use a gradle task to copy them (because they aren't copied from common code to platform resources). We also do this with SVG's (which are rendered as composables in Compose HTML, or used in backend kotlinx.html code). For the HTML target the resources and up in the web-app root folder, so we just use fetch as a loader in the browser. In backend code we just use ClassLoader.resourceAsStream

We haven't run into any problems so far or haven't found usecases that we couldn't support. It's basically just plain old SOLID principles. When you are not a library creator but an application creator you don't need a lot of externals of expects or actuals. Simple interfaces and implementations work fine.

But it can be that the problems other people run into we might still run into in the future.

[Robert Jaros]

But perhaps you can tell how do you process "po" files (I assume gettext files) in KMP?

[Arjan van Wieringen]

Just parse them yourself? They aren’t that difficult

[Robert Jaros]

People are making libraries for this 😉 https://github.com/kropp/kotlinx-gettext

[Arjan van Wieringen]

True, for JVM and JS only and documentation is limited. And loading of the files in JS still requires me to do a fetch.

[Arjan van Wieringen]

Nothing wrong with libraries, but for extremely basic functionality there's nothing wrong with sometimes rolling your own. If I wanted a library for every basic feature I'd start writing nodejs code. If I'd use the aforementioned library I'd have the basic same functionality but now with a dependency on someone I don't know for I don't know how long with a Gradle Plugin and a Kotlin Compiler Plugin..... no thank you. Way overengineered for something so basic.