The Compose App Wizard was updated too! - added Pr...

# feed

[Konstantin Tskhovrebov]

The Compose App Wizard was updated too!
• added PreCompose and Decompose libraries
• added cross link to my KMP library wizard
• added link to the KMP-awesome libraries list
https://terrakok.github.io/Compose-Multiplatform-Wizard/

[Michael Paus]

Why do you use Kermit for logging in the KMP Library Wizard but Napier in the Compose Multiplatform Wizard. Isn’t that inconsistent?

[Konstantin Tskhovrebov]

I like the Napier, but it doesn't support some native targets like the windows

[Michael Paus]

And when you use some KMP libraries in a Compose multiplatform project don’t you have to configure two different logging environments then?

[Konstantin Tskhovrebov]

If i want to publish a library in public I will not use a lot of dependencies. Like logger, di or else.

You speak about a common problem: what dependencies to use in libraries

[Konstantin Tskhovrebov]

Everyone has to solve it for each specific case

[Konstantin Tskhovrebov]

There's a slightly different topic: what is a difference between a library and a SDK.
For SDKs it is ok to have dependency on di, loggers, network stuff etc.

But usually a typical app has only few SDKs inside.
So, I guess, it is fine to have more than one logger. 🙂

[Stefan Oltmann]

I pondered the same considerations and eventually opted not to implement logging or Dependency Injection (DI) in my libraries.

For numerous Java libraries, the built-in logging can be bothersome, especially when it's built using Apache logging (though I personally use log4j). The situation improved somewhat with the introduction of slf4j, but it still wasn't ideal.

[Michael Paus]

Exactly. A pure logging facade like SLF4J or no logging at all is what one should use in libraries. This is common practice in Java today but for whatever reason was not carried over to Kotlin. Even a framework should not depend on any specific logger.

[Stefan Oltmann]

Yes, Kotlin stdlib should provide an interface like slf4j. If Kermit is the de facto standard its interface could be included into the standard lib, so most people won’t need to change anything.

I don’t know if that’s anywhere the case with Kotlin, but Java API has some interfaces included without providing an implementation. At least I remember it so.

At the time I started with Photos Kermit had some issues and I went crafting my own custom logging in Photos. Since it works I never felt the need to migrate to Kermit.

The introduction of an official logging interface could change that as I love standards. 😄

[Konstantin Tskhovrebov]

The kermit is not a standard though. Napier is my personal choice. I guess because it seems like the Timber

[Stefan Oltmann]

You have the power to define how the interface to logging must/should look like. The actual implementation doesn't matter that much.

[Alexandre Bianchi]

Newbiee learning question: This is for Compose Platform new concept, or KMP, KMM?
My questions is because the official template only has 4 targets, don't have jsMain: Android, iOS, Desktop, Web(Wasm).

[Konstantin Tskhovrebov]

Yes. I don't provide the wasm because it was just released and libraries don't support it yet.

[Alexandre Bianchi]

Thank you!