Skip to content

Remove Native classes from Public API #555

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

Merged

Conversation

Daeda88
Copy link
Contributor

@Daeda88 Daeda88 commented Jun 26, 2024

Fixes based on comment #550 (comment)

Daeda88 added 2 commits June 26, 2024 16:10
public final fun removeValue (Lkotlin/coroutines/Continuation;)Ljava/lang/Object;
public final fun setEncodedValue (Ljava/lang/Object;Lkotlin/coroutines/Continuation;)Ljava/lang/Object;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why have these been added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we have a bunch of inline methods that need access to the Native classes. Though those had been set as internal and annotated with @PublishedApi, this results in them still poping up in the API specification.

So it's essentially choosing between having the Native... classes in the api or these methods. I want for these because it makes the API "smaller"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify: these methods are also marked as@PublishedApi internal fun and the access the native classes inside their code. As a result the Native classes no longer need to be Published, but the method does because public inline methods can only call publish/Published code

public final fun setValue (Lkotlinx/serialization/SerializationStrategy;Ljava/lang/Object;Lkotlin/jvm/functions/Function1;Lkotlin/coroutines/Continuation;)Ljava/lang/Object;
public final fun setValue (Lkotlinx/serialization/SerializationStrategy;Ljava/lang/Object;ZLkotlin/coroutines/Continuation;)Ljava/lang/Object;
public static synthetic fun setValue$default (Ldev/gitlive/firebase/database/OnDisconnect;Lkotlinx/serialization/SerializationStrategy;Ljava/lang/Object;Lkotlin/jvm/functions/Function1;Lkotlin/coroutines/Continuation;ILjava/lang/Object;)Ljava/lang/Object;
public final fun updateChildren (Ljava/util/Map;Lkotlin/jvm/functions/Function1;Lkotlin/coroutines/Continuation;)Ljava/lang/Object;
public final fun updateChildren (Ljava/util/Map;ZLkotlin/coroutines/Continuation;)Ljava/lang/Object;
public static synthetic fun updateChildren$default (Ldev/gitlive/firebase/database/OnDisconnect;Ljava/util/Map;Lkotlin/jvm/functions/Function1;Lkotlin/coroutines/Continuation;ILjava/lang/Object;)Ljava/lang/Object;
public final fun updateEncodedChildren (Ldev/gitlive/firebase/internal/EncodedObject;Lkotlin/coroutines/Continuation;)Ljava/lang/Object;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why have these been added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nbransby
Copy link
Member

Understood, do these @PublishedApi function appear in the kdocs I wonder.

Does this change also mean the ios, android and is properties don't need to be extensions?

@Daeda88
Copy link
Contributor Author

Daeda88 commented Jun 26, 2024

Afaik internal methods marked with @PublishedApi are not accessible from kotlin, but they are from Java. So I don't think they need Kdoc.

As for the extensions for android/ios/JS, they are still needed as they extend the classes that are in common code, e.g 'Query', to provide access to the Native classes (e.g. 'NativeQuery'). It used to be that these native classes, usually Typealiases, where public as well, but with this change all of that is internal. So in order to still support construction with platform specific code I added some 'invoke' methods to the companion objects though extension as well.

That means, you can still do 'Query(androidQuery)' on platform code, but no longer from common code and it requires an import of 'dev.gitlive.firebase.firestore.invoke'.

@@ -34,14 +34,16 @@ public expect val Firebase.firestore: FirebaseFirestore
/** Returns the [FirebaseFirestore] instance of a given [FirebaseApp]. */
public expect fun Firebase.firestore(app: FirebaseApp): FirebaseFirestore

public expect class NativeFirebaseFirestore
internal expect class NativeFirebaseFirestore

public class FirebaseFirestore internal constructor(private val wrapper: NativeFirebaseFirestoreWrapper) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving comments to illustrate what I mean.

This class in common is the class users interact with. It is not an expect actual class and as such, to have the android/ios/js accessors, we need to write extension values on the platforms


// Important to leave this as a get property since on JS it is initialized lazily
public val native: NativeFirebaseFirestore get() = wrapper.native
internal val native: NativeFirebaseFirestore get() = wrapper.native
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This used to be a common level alternative to android/ios/jsbut it is now internal, becauseNativeFirebaseFirestore` is now internal

public constructor(native: NativeFirebaseFirestore) : this(NativeFirebaseFirestoreWrapper(native))
public companion object {}

internal constructor(native: NativeFirebaseFirestore) : this(NativeFirebaseFirestoreWrapper(native))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since NativeFirebaseFirestore is now internal, the constuctor has to be as well


public class FirebaseFirestore internal constructor(private val wrapper: NativeFirebaseFirestoreWrapper) {

public constructor(native: NativeFirebaseFirestore) : this(NativeFirebaseFirestoreWrapper(native))
public companion object {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -34,14 +34,16 @@ public expect val Firebase.firestore: FirebaseFirestore
/** Returns the [FirebaseFirestore] instance of a given [FirebaseApp]. */
public expect fun Firebase.firestore(app: FirebaseApp): FirebaseFirestore

public expect class NativeFirebaseFirestore
internal expect class NativeFirebaseFirestore
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a typealias to FIRFirestore(ios) and com.google.firebase.firestore.FirebaseFirestore(android) or the wrapper on Javascript. To remove it from the public API, it is now internal but this has a cascading effect on
https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/555/files#r1655371860
https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/555/files#r1655371283


public val FirebaseFirestore.android: NativeFirebaseFirestore get() = native
public operator fun FirebaseFirestore.Companion.invoke(android: AndroidFirebaseFirestore): FirebaseFirestore = FirebaseFirestore(android)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the public construcor gone (see https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/555/files#r1655371860), in order to still support FirebaseFirestore(android: AndroidFirebaseFirestore) we can add an extension to the companion object https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/555/files#r1655372358

This maintains the same syntax, but since it is an extension method, it does require an explicit import

@nbransby
Copy link
Member

ok so ill finish the breaking change of converting all .js, .android, .ios properties to extensions in #504

@nbransby
Copy link
Member

Afaik internal methods marked with @PublishedApi are not accessible from kotlin, but they are from Java. So I don't think they need Kdoc.

Yes they dont need a docblock but I still wonder if dokka will publish them in the api docs

@nbransby nbransby merged commit 6439a1c into GitLiveApp:master Jun 27, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants