Anyone else think Google's <Jetpack Compose API re...

# compose

[darkmoon_uk]

Anyone else think Google's Jetpack Compose API reference is just awful?
It has all the Jetpack packages combined into a single space, so that you can't easily separate one (i.e. Compose) from any other. Search that doesn't indicate which package/library a result is from, and parts of compose split across packages in a way that makes it hard to locate anything - useless... the JetPack Playground documentation is unofficial, possibly out of date, but does a far better job of being usable.

[Timo Drick]

In the last months there where many major changes in the package structure. In my opinion it starts to clear up and it improved a lot since than. Also the API reference is much better than the reference of the old legacy view system because it includes sample code and explanation how to use things.
Of course it is not perfect but i think the compose devs are on the right way.
There is a (i think official) codelab: https://developer.android.com/codelabs/jetpack-compose-basics

[Colton Idle]

I'm sure they will update the docs as we approach stable. I know right now I have a very hard time of just jumping in and knowing which composables to use and basic usages of them, but the compose pathway is really helpful https://developer.android.com/courses/pathways/compose

and the source code demos are also helpful, but I wish there was a better way to find them as theyre scattered in different places.

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:co[…]oidx/compose/material/samples/ButtonSamples.kt?q=ButtonSample

[Zach Klippenstein (he/him) [MOD]]

Locating which maven dependency you need for a given API is a problem that would be nice to solve even with non-Compose code. But the improved and simplified artifacts of late make this a little easier to guess right at least.

The biggest issue from my perspective is just that no kotlin documentation tools are designed to expose functions, or groups of functions, as logical top-level concepts in the way Compose uses them. When you search for a class, you get a nice single page that documents the class and all it’s related methods and types. In compose, you’re often looking for documentation about some logical component like Box, which isn’t a type but a function, and actually a few different functions with the same name. The search tools don’t surface the high level Box concept very well (at best, google will give you a generic looking page with a “Jump to Box” link), and there’s no central place to view everything related to Boxes.

I think this is not because the docs aren’t there or are poorly written (the amount and quality of documentation for composables is actually really impressive for the most part), it’s that nobody has really written Kotlin apis like this before.

[Zach Klippenstein (he/him) [MOD]]

I don’t know if google is using dokka for the official docs but it would be nice to solve this in dokka because it’s a problem anyone writing compose libraries is going to face.

[Zach Klippenstein (he/him) [MOD]]

Definitely want to give kudos to the team though on the general quality of documentation, the use of samples, etc.

[Mark Murphy]

Locating which maven dependency you need for a given API is a problem that would be nice to solve even with non-Compose code.

FWIW, for classes, the android.tech class lists can get you to the artifact fairly quickly. For example, classes beginning with A are at https://androidx.tech/classes/A. It shows each class and all the artifacts the class appears in, where each artifact leads you to versions that contain the class.

I haven't attempted to address the top-level-function problem.