Looking at the KMMBridgeKickstart … Can someone ex...

# touchlab-tools

[Bradleycorn]

Looking at the KMMBridgeKickstart … Can someone explain why the analytics module is listed as an api() dependency (and is exported in the cocoapods configuration)?

[russhwolf]

I think that was to save needing to forward calls through the umbrella module. We went back and forth a bunch internally over how much detail we wanted to go into in that module structure.

[russhwolf]

analytics is a relatively simple API so exposing that isn't as heavy as exposing something like a bunch of database tables

[Bradleycorn]

So, it was “we chose to” and not, “we had to”, right?

[russhwolf]

correct

[Bradleycorn]

👍

[Bradleycorn]

Soo … here’s something I’ve noticed anecdotally …

My allShared module has a dependency on another module called adw-program.
adw-program defines a class, called Program .
allShared defines a class called IosContainer.
IosContainer has a function, getProgram() that returns an instance of Program.

in my allShared module, if i use implementation for the adw-program dependency, and don’t export it via the cocoapods framework, then in my swift code, the Program class’s type is actually Adw_programProgram … Also, any of the other classes in my adw-program module are NOT available at all in my ios/swift project. the Adw_programProgram class is available only because the IosContainer has a method that returns an instance of it.

However, if I make the adw-program an api() dependency (and export it via cocoapods), then things in Swift are more “what you would expect”. I have a Program class, and I can see all of the (public) classes declared in adw-program.

[russhwolf]

yeah, that's about what I would expect. If you export, you'll get everything without a prefix. If you don't export, you'll get only the minimal set of things that are exposed via the public API of your top-level module, and they will be prefixed

[russhwolf]

One option for more fine-grained control is to split adw-program into two separate modules. One has just the public API that you'll expose through allShared and the other has impls and internal details. Then you can export the API module but still control what gets exported based on whether it's in the api or the impl module, and you won't see the module name prefix on things from the api module.

[Bradleycorn]

yeah, that’s kind of what I’m doing. adw-program exposes my “Repository”, and there are additional modules for adw-network, adw-storage , etc that have the ktor and sqldelight stuff. I also have adw-models that contains all of the models (data classes), so that one I definitely want to use api exports for.

[Bradleycorn]

So I’ll probably end up with adw-program and adw-models being exported api’s, and all the others being implementations that are kept “internal” to the library