Over the past year, Jetpack Compose has revolutionized the Android landscape. Its intuitive syntax has significantly simplified the work of engineers. The creation of complex UI components, which was once a daunting task, is now a breeze. With just the use of a Modifier, you can create in minutes what would have taken hours or even been impossible to create in XML. This efficiency is making Jetpack Compose increasingly popular each day.
The Naming Convention Dilemma
Any seasoned Jetpack Compose user is aware of an unspoken rule regarding the naming of composables in an Android App. The norm is to name functions that return Unit and that is annotated with the @Composable tag using PascalCase, resulting in names like PrimaryButton, SecondaryButton, ExampleStateSuccess, ExampleStateLoading, ExampleStateError, and so forth. However, after reading an article by Christopher Keenan, I began to question this naming convention and noticed a few issues that had been bothering me but I had chosen to ignore them.
For instance, what happens when you have similar items with easily confusable names, leading to hours of trying to decipher which is which? Or what about excessively long names that compromise readability? I’ve encountered such instances in the past with names like ParkingLocationMapDetailsSuccess, ParkingLocationMapDetailsError, ParkingLocationMapDetailsLoading, PrimaryLargeButton, SecondarySmallButton, and the list goes on.
Proposed Solution
We could adopt a slightly unconventional approach that may not seem intuitive initially. We could encapsulate similar or related composables into Object and use the invoke operator for the main composable.