-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing fields added to AuthResult #556
Conversation
Adds missing fields to AuthResult and makes its constructor public
# Conflicts: # firebase-auth/src/androidMain/kotlin/dev/gitlive/firebase/auth/auth.kt # firebase-auth/src/commonMain/kotlin/dev/gitlive/firebase/auth/auth.kt # firebase-auth/src/iosMain/kotlin/dev/gitlive/firebase/auth/auth.kt # firebase-auth/src/jsMain/kotlin/dev/gitlive/firebase/auth/auth.kt # firebase-auth/src/jsMain/kotlin/dev/gitlive/firebase/auth/externals/auth.kt # firebase-auth/src/jvmMain/kotlin/dev/gitlive/firebase/auth/auth.kt
firebase-auth/src/iosMain/kotlin/dev/gitlive/firebase/auth/auth.kt
Outdated
Show resolved
Hide resolved
@@ -113,9 +113,28 @@ public actual class FirebaseAuth internal constructor(public val android: com.go | |||
public actual fun useEmulator(host: String, port: Int): Unit = android.useEmulator(host, port) | |||
} | |||
|
|||
public actual class AuthResult internal constructor(public val android: com.google.firebase.auth.AuthResult) { | |||
public actual class AuthResult( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why cant the constructor stay internal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just feel like there is no need for it to be internal. Having it public just allows more flexibility for the library. People can define their own extensions for stuff that is platform specific etc (like my example) and still keep the common types from the library.
I mean sure, in my example I could redefine the AuthResult
in my own code and use that instead and this PR kinda removes the need for that code all together. But still the constructor being internal seems like an unnecessary obstacle forcing me to write something that is already there, while offering not much benefit elsewhere.
It's definitely up to discussion, depends if there are any more serious reasons for it to be internal in the first place.
Thanks for this. Issue 1 is fine. Issue 2 you can just write a test to get the new fields you've added and assert they are the values you expect, the test will run on all platforms and will fail on JS if you have got a property name wrong |
Well the problem is that I don't really know what values to expect from the testing |
Ok well commit the test, let the CI run it and we'll take it from there |
@mr-kew you can review the test reports now to see what is failing, also maybe add some messages to the assert calls so you know which ones are failing. Also the lint is failing too |
@nbransby Hm, I have no idea why the lint fails. It fails in The tests are failing on the first assert for |
scroll up and it tells you what the issue are:
|
How do we do this? |
I have no idea, I was hoping you would help me with that. It seems the tests are accessing some regular firebase project, but I don't have a permissions (and don't really want them) to do anything with that. |
Yes I can edit it just not sure what you need doing |
Hmm, I'm really not entirely sure either. In my project, the additional info & credential come from the SSO. To test it we are using Okta, which then after From the Firebase docs it looks like the additional info is indeed not null only while using the Additional issue is that the okta sign in redirects to okta sign in form in browser, so idk if it is possible in unit tests without running the app. |
Ok well for now I guess we can simply update the test to confirm the values are null - that will at least assert no exceptions are thrown |
Yeah, that makes sense. If someone discovers it's not working later, it can be solved as a separate issue. |
Tests for null using optional unwrap don't make much sense
@nbransby Android & JVM tests are now passing, but iOS and JS does not show my assert messages so I don't know how exactly is the test failing. Can I somehow access the file with results?
|
You can find the test reports here: https://github.com/GitLiveApp/firebase-kotlin-sdk/actions/runs/9940703433?pr=556#artifacts |
Exact values differ on different platforms
JS tests still falling with |
firebase-auth/src/jsMain/kotlin/dev/gitlive/firebase/auth/externals/auth.kt
Outdated
Show resolved
Hide resolved
@nbransby Yeah, it might be JSON, nice find. But from the exception it seems like there is an issue with FirebaseApp initialization in the tests. So the test itself does not even run, I think. So I still can't verify it. |
@nbransby So I fixed the js tests (it was about the position of the test code in a file), but I had to make them more forgiving because in JS the But I think it is fine
|
Ok, btw there are conflicts you'll need to resolve before we can merge it in |
firebase-auth/src/androidMain/kotlin/dev/gitlive/firebase/auth/auth.kt
Outdated
Show resolved
Hide resolved
firebase-auth/src/iosMain/kotlin/dev/gitlive/firebase/auth/auth.kt
Outdated
Show resolved
Hide resolved
firebase-auth/src/jsMain/kotlin/dev/gitlive/firebase/auth/auth.kt
Outdated
Show resolved
Hide resolved
@nbransby Really thank you for all the help. It was quite complicated and I wouldn't have managed it all on my own. |
No problem, it was 99% all you! |
I added all the missing fields to
AuthResult
type and also made it's constructor public, so it can be used to pass data from platform specific methods back to commonMain.Example:
I wanna use signInWithProvider which is available only in
platformMain
. It will probably never be available incommonMain
because of theactivity
parameter. So I make a method for it. It takescommonMain
typeOAuthProvider
.Before this PR:
androidMain:
commonMain:
Issues
JVM version does not provide some fields at all. I used
throw NotImplementedError()
to communicate that in commonMain.I have a problem with testing this. Can anyone give me some advice? I should verify whether all the fields are actually present in js, but I don't really know how to test that. With iOS and android it should be fine as the result is properly typed.