https://kotlinlang.org logo
#compose-web
Title
# compose-web
d

David Herman

03/17/2024, 3:05 AM
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/)
r

Robert Jaros

03/17/2024, 6:12 AM
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
thank you color 1
a

Arjan van Wieringen

03/17/2024, 7:29 AM
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.
r

Robert Jaros

03/17/2024, 7:32 AM
I would like to use
strings
to support different languages.
2
And I personally work with
common
code, so I can't just access these resources in my code.
a

Arjan van Wieringen

03/17/2024, 8:55 AM
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.
r

Robert Jaros

03/17/2024, 8:57 AM
Can you share your solution?
a

Arjan van Wieringen

03/17/2024, 9:28 AM
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.
🙏 1
r

Robert Jaros

03/17/2024, 9:47 AM
But perhaps you can tell how do you process "po" files (I assume gettext files) in KMP?
a

Arjan van Wieringen

03/17/2024, 10:01 AM
Just parse them yourself? They aren’t that difficult
r

Robert Jaros

03/17/2024, 10:29 AM
People are making libraries for this 😉 https://github.com/kropp/kotlinx-gettext
a

Arjan van Wieringen

03/17/2024, 10:33 AM
True, for JVM and JS only and documentation is limited. And loading of the files in JS still requires me to do a fetch.
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.
15 Views