Make Showkase annotations more general and extendable
micHar opened this issue · comments
Hello @vinaygaba,
First of all, let me say that I love this lib. My team is using it, we are now mostly using the metadata generation and implemented our own gallery for it. We also want to use it for screenshot testing but been having some issues.
Now, we've been thinking about different use cases for the lib and since right now it's been our main engine to collect the design system metadata via annotations, we were wondering about extendability.
The high level concept would be to have custom annotations which would descend from showkase annotations. Showkase would analyse them through ksp, but of course would have to know what to do with the types and functions annotated with them, so it would require an additional mechanism of transformers, which would take the annotated type/function and transform it into the metadata or into something visual.
It might also make the existing color/typography/composable annotations more useful since we could transform the effects into composables of users choice and use them inside a custom gallery. Right now you either have to use the default gallery or build a new one completely from scratch - not usre about that use case though. You're thinking about different additional use cases as well afaik, like spacing or icons / assets.
It's a general high level idea for now, let me know if it's itneresting, I might be able to help if it is.
@micHar We recently added a new field to ShowkaseComposable called extraMetadata to allow extending the annotation for custom use cases that we had internally - https://github.com/airbnb/Showkase/blob/master/showkase-annotation/src/main/java/com/airbnb/android/showkase/annotation/ShowkaseComposable.kt#L76.
This is a string field, however you can build additional IDE tooling to make the string more type safe. We ended up adding auto complete support the same way the device field inside @Preview handles it. Look at the screenshot here to get an idea about what I mean - https://developer.android.com/jetpack/compose/tooling/previews#different-devices
All this to say that this might end up being sufficient for extending this library further for your custom use cases. You might need to build some tooling but from the standpoint of a library, it ensures that the API remain clean, while still being flexible.