Thread
#compose
    s

    Saiedmomen

    1 year ago
    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.
    Halil Ozercan

    Halil Ozercan

    1 year ago
    which classes or functions do you want to have access? I'd imagine it's about drag gestures 🙂
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    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.
    s

    Saiedmomen

    1 year ago
    Library developers shouldn't opt in
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    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.
    Copy-paste is verbose and inconvenient, but is safe.
    s

    Saiedmomen

    1 year ago
    I think there are lint/compiler plugin ways for preventing opt in on library modules.
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    Buy it is still up to library developers to apply the rule/plugin, right?
    s

    Saiedmomen

    1 year ago
    They can choose to ignore them.
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    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

    1 year ago
    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
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    Experimental API is the API being tested, so there is intention to make it eventually stable.
    s

    Saiedmomen

    1 year ago
    @Halil Ozercan There has been a few. This one for examplehttps://kotlinlang.slack.com/archives/CJLTWPH7S/p1621754724158200
    Adam Powell

    Adam Powell

    1 year ago
    +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

    1 year ago
    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
    Adam Powell

    Adam Powell

    1 year ago
    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
    especially if upstream changes are thereby incapable of breaking your code
    s

    Saiedmomen

    1 year ago
    There is also an
    @InternalCoroutinesApi
    annotation in Coroutines that I encountered today.
    /**
     * 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
    Arkadii Ivanov

    Arkadii Ivanov

    1 year ago
    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 🔥 🙃
    s

    Saiedmomen

    1 year ago
    I see your point 🙂
    thanks for the clarification