API suggestions

[dalewking]

Starting to use this library now, there are a couple of API suggestions I have:

• DebugDrawerInfo takes a String for the info parameter. Why isn't that just of Any? type and then you do the toString on that. That makes it easier to use. You could add this as an overload of the existing function
• The API uses strings for the id of drawer regions. This should really just be of type Any to allow for things like an enum or sealed class hierarchy to identify regions. You could make it a generic Type parameter, but that might get messy as then DrawerState would have the type parameter and region

[MFlisar]

DebugDrawerInfo takes a String for the info parameter. Why isn't that just of Any? type and then you do the toString on that. That makes it easier to use. You could add this as an overload of the existing function

the info parameter is a text, because it is rendered as text

https://github.com/MFlisar/ComposeDebugDrawer/blob/00e3059577444ae82d5667fbea13bd7e8a7611f1/library/core/src/commonMain/kotlin/com/michaelflisar/composedebugdrawer/core/composables/DebugDrawerInfo.kt#L31

it does not make sense to use another type here... it's a user choice to show object.toString() here and in such a case it's obvious that the info parameter will be used as string...

The API uses strings for the id of drawer regions. This should really just be of type Any to allow for things like an enum or sealed class hierarchy to identify regions. You could make it a generic Type parameter, but that might get messy as then DrawerState would have the type parameter and region

It could be an Int which is often used in such cases as well. This one would work well with enums... Any would always be to generic imho...

I decided to use a string because it defaults to the label and because I assume that in a real world app you won't have the same label multiple times here so mostly the user does not have to provide an id at all... At least I never needed to provide an id manually yet...

[dalewking]

DebugDrawerInfo takes a String for the info parameter. Why isn't that just of Any? type and then you do the toString on that. That makes it easier to use. You could add this as an overload of the existing function

the info parameter is a text, because it is rendered as text

ComposeDebugDrawer/library/core/src/commonMain/kotlin/com/michaelflisar/composedebugdrawer/core/composables/DebugDrawerInfo.kt

Line 31 in 00e3059

text = info, it does not make sense to use another type here... it's a user choice to show object.toString() here and in such a case it's obvious that the info parameter will be used as string...

But consider the simple cases of just wanting to show and int, boolean or enum. You are making the user have to add the toString for no real good reason. It add nothing to force the type to be String. As I said, at the very least you could add an overload of type Any? that forwards to the String version.

The API uses strings for the id of drawer regions. This should really just be of type Any to allow for things like an enum or sealed class hierarchy to identify regions. You could make it a generic Type parameter, but that might get messy as then DrawerState would have the type parameter and region

It could be an Int which is often used in such cases as well. This one would work well with enums... Any would always be to generic imho...

I decided to use a string because it defaults to the label and because I assume that in a real world app you won't have the same label multiple times here so mostly the user does not have to provide an id at all... At least I never needed to provide an id manually yet...

I just very much favor strong typing and I view String as too generic.

[MFlisar]

DebugDrawerInfo

The info parameter is passed to the Text composable - this does take a string so I expose a string... It does not make sense to expose Any and call toString on it. The DebugDrawerInfo composables displays an info text, the text is passed on to a Text composable and texts are just Strings...

If you want to support any, just write the overload for yourself.

Keys

If there is no need for a custom class for keys, the usage of String, Int and Long are very common... (RecyclerView ids and View ids are numeric, WorkManager ids are a String and so on...). No need for a anything more complex for such a simple use case, its very common. And as I said, normally you don't need to provide an id anyways.