https://kotlinlang.org logo
#compose
Title
# compose
s

Saiedmomen

06/01/2021, 11:20 AM
A lot of classes and functions that we could use to build our own components are
internal
or
private
. I know the reason for limiting the public API but an optIn annotation might be enough. Right now we have to copy huge amounts of code in order to have a working custom component. Code that won't get maintained or fixed easily. If we could opt in to them, our code would break on upgrades but we would still get the benefits and fixes after fixing them.
One could still not opt in and copy and have a more stable and less up to date repo.
h

Halil Ozercan

06/01/2021, 11:34 AM
which classes or functions do you want to have access? I'd imagine it's about drag gestures 🙂
🙌 2
a

Arkadii Ivanov

06/01/2021, 11:50 AM
In this case such an API will be effectively public. This will open doors for binary compatibility issues when there are transitive dependencies using the API.
1
s

Saiedmomen

06/01/2021, 11:56 AM
Library developers shouldn't opt in
a

Arkadii Ivanov

06/01/2021, 11:59 AM
I think we can't prevent it. My concern is that end users will be affected at the end, and the failure will happen at runtime, which can affect production.
1
Copy-paste is verbose and inconvenient, but is safe.
s

Saiedmomen

06/01/2021, 12:08 PM
I think there are lint/compiler plugin ways for preventing opt in on library modules.
a

Arkadii Ivanov

06/01/2021, 12:09 PM
Buy it is still up to library developers to apply the rule/plugin, right?
s

Saiedmomen

06/01/2021, 12:10 PM
They can choose to ignore them.
a

Arkadii Ivanov

06/01/2021, 12:12 PM
Ok, I'm not sure what particular rules/plugins you mean, but if there is a way for library devs to use the internal APIs, they will do it. As a result, end users will be silently affected. So this is my concern here.
s

Saiedmomen

06/01/2021, 12:14 PM
I completely understand. On the other hand compose-ui modules are different from say coroutine and there are many valid use cases for customizing them.
On the other hand there are already opt in annotations for experimental api's that have the same issue
a

Arkadii Ivanov

06/01/2021, 12:30 PM
Experimental API is the API being tested, so there is intention to make it eventually stable.
👍 1
s

Saiedmomen

06/01/2021, 12:59 PM
@Halil Ozercan There has been a few. This one for example https://kotlinlang.slack.com/archives/CJLTWPH7S/p1621754724158200
a

Adam Powell

06/01/2021, 1:25 PM
+1 to everything @Arkadii Ivanov said above. Everything at the layer of compose-foundation and above can be done from libraries and apps without making some of these other internals public, albeit with some additional work.
Not all of these internals are designed to be API in the first place; many of them are kind of raw utilities instead of clear, single-purpose concepts. Some of them have changed dramatically in the course of performance optimizations or learning how to write compose code more effectively
Compose wasn't designed and written in waterfall style, a great many of the patterns and best practices documented and promoted today are the result of us trying things out and learning the hard way. 🙂 Some internals still use some patterns that may have been mechanically sound, but we may now favor patterns that are more consistent with what we do elsewhere if we were to promote more into the public API surface
s

Saiedmomen

06/01/2021, 1:47 PM
I'm just saying that having to copy 500 lines, change 3 lines to have a three anchor bottomsheet is not ideal. Maintaining and syncing the libraries/applications with latest upstream improvements would be quite cumbersome don't you agree? I think a more tinker friendly api would be really nice. There might be better approaches than opt in annotations.
like for example having the intent to eventually publicize some of these utilities
a

Adam Powell

06/01/2021, 1:59 PM
I do not agree. 🙂 I think that an API where you can open up the source of its internals and press ctrl+c, ctrl+v, make any alterations you like, and be on your way within minutes is profoundly tinker-friendly
🙂 4
🆗 2
2
especially if upstream changes are thereby incapable of breaking your code
1
s

Saiedmomen

06/03/2021, 6:48 PM
There is also an
@InternalCoroutinesApi
annotation in Coroutines that I encountered today.
Copy code
/**
 * Marks declarations that are **internal** in coroutines API, which means that should not be used outside of
 * `kotlinx.coroutines`, because their signatures and semantics will change between future releases without any
 * warnings and without providing any migration aids.
 */
@Retention(value = AnnotationRetention.BINARY)
@Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION, AnnotationTarget.TYPEALIAS, AnnotationTarget.PROPERTY)
@RequiresOptIn(
    level = RequiresOptIn.Level.ERROR, message = "This is an internal kotlinx.coroutines API that " +
            "should not be used from outside of kotlinx.coroutines. No compatibility guarantees are provided." +
            "It is recommended to report your use-case of internal API to kotlinx.coroutines issue tracker, " +
            "so stable API could be provided instead"
)
public annotation class InternalCoroutinesApi
a

Arkadii Ivanov

06/03/2021, 7:01 PM
Yes, and as it is mentioned in the comment it should not be used. Otherwise issues like this will happen: https://youtrack.jetbrains.com/issue/KT-46697. In this particular case Ktor used there internal API and depended on an older version of coroutines. lucky Kotlin/Native caught the issue at linking time. JVM would crash at runtime. So it is like playing with fire 🔥 🙃
🔥 2
s

Saiedmomen

06/03/2021, 7:13 PM
I see your point 🙂
thanks for the clarification
2 Views