In a way it feels extra to have those functions as composable. Since it is multiplatform, one might not want compose, maybe they have React and now they will need to be using compose too. Or maybe in future if we have a native library that is compiled to native, then it might be called not from Kotlin, but from many different languages....
There could be 2 kinds of library maybe, one without compose and one with compose? something like implementation("com.darkrockstudios:mpfilepicker:1.1.0") and implementation("com.darkrockstudios:mpfilepicker-compose:1.1.0").
ya I think that makes sense. I think lets focus first on just getting the multi-platform implementations done, then re-structure it into multiple libraries.
In a way it feels extra to have those functions as composable. Since it is multiplatform, one might not want compose, maybe they have React and now they will need to be using compose too. Or maybe in future if we have a native library that is compiled to native, then it might be called not from Kotlin, but from many different languages....
Similar thing happened here https://github.com/Wavesonics/compose-multiplatform-file-picker/pull/17, i had to add a separate module, bucause then I get error
:mpfilepicker:mingwX64Main: Could not resolve org.jetbrains.compose.foundation:foundation:1.3.0.
There could be 2 kinds of library maybe, one without compose and one with compose? something like
implementation("com.darkrockstudios:mpfilepicker:1.1.0")
andimplementation("com.darkrockstudios:mpfilepicker-compose:1.1.0")
.