Compose extension library

[jan-tennert]

Hey, I just wanted a few extra opinions about this idea. The current situation is if you want e.g. implement Native Login you have to implement it by yourself or use 3rd-party libraries to make it easier for you. We could make an extension library that provides components like this.

Specifically, it would be:

• Native Login (Google OneTap, etc.)
• Captcha
• Auth Components like a Password & Email Fields with content validation, 2FA Code Field etc.
• possibly more (?)

Please tell me what you think about this idea and feel free to share your opinion and suggestions!

[temk0]

I wonder if we should have a login config for all native providers so e.g. googleLoginConfig, appleLoginConfig etc., not just one? So for now we could have a googleLoginConfig?

Thats what I intended. I created LoginConfig and the GoogleLoginConfig extends it.
Also Im not sure if we should put all the providers in one module. Reason why is that almost all of them require its own library and configuration. Question is will the dev mind having other dependencies that they dont use or implement

I see what you mean, but then the question is how we provide other native login methods. Maybe we could store the login configs in a map, and then we provide additional dependencies like compose-auth-apple or compose-auth-facebook which extend on this. What do you think?

We can use that as initial implementation and build on it. The current install of modules enables us to provode compose extensions on-domain, also the authProvider abstraction in GoTrue-kt can be followed to make it more flexible in the future.

This thread is getting long we can continue it in the open discussion #233

Posting the thread from #241 so it can be continued if necessary

[jan-tennert]

Okay, so currently there is no way to extend the ComposeAuth plugin with more providers, and you can only use one at a time.
I'm thinking that we make a map property in the ComposeAuth config:

val loginConfigs = mutableMapOf<String, LoginConfig>

And then seperate modules have extension functions like

fun ComposeAuth.googleNativeLogin(..) {
    loginConfigs["google"] = config
}

And then access the config again with

composeAuth.loginConfigs["google"] as GoogleLoginConfig

or maybe even provide a function like

inline fun <reified T> ComposeAuth.loginConfig(key: String) = loginConfigs[key] as T

Providing that will make it easier for us to add more implementation on top of the Google one.

[jan-tennert]

On top of that, I would suggest we would extract the Google implementation of the core plugin and maybe even provide a separate module as planned for other providers so that you can add Google separately.

[temk0]

As now Both Native login flows are included Google(android) and Apple(iOS). To use them the respected config should be provided, otherwise the fallback logic will be triggered.
Am also in favor of separating the Core logic with providers, that is the case only with Google because the Apple Auth API ships with the kotlin.multiplatform plugin therefore idk if we should separate that option from the Core

[jan-tennert]

yea makes sense

[temk0]

As an additional providers I was wondering if is possible to support biometrics

[jan-tennert]

once supabase supports it 👍

[temk0]

Question from #256 : Are the Provider Button are reserved for the OAuth providers and Native Login?

I suggest the future native login modules provide some default compose UI, and this to be only with the built in methods of login

[jan-tennert]

Yes I planned them for OAuth providers

[jan-tennert]

Already implemented.