For closure actions that get passed to @Composables, I'm finding I go back and forth between parameter names that are either 1) onXyz (e.g.

onEdit

,

onChange

,

onClick

,

onClose

) or 2) xyxAction (e.g.

editAction

,

changeAction

,

clickAction

,

closeAction

). Is there any convention (published or not) for how others tend to name these? I feel like I should pick and stick with one or the other. Vote 1️⃣ for the first, and 2️⃣ for the second. Or answer a third type :D

1st party APIs that ship with compose itself stuck to

on*

names

and I'll add that the convention (I believe I read this in the official docs) is to use present tense, so

onClick

as opposed to

onClicked

So is that an argument to "when in rome" or to do the alternate so as to distinguish own code from 1st party?

my persional opinion is to do the same, whether you call a 1st party composable or one of your own, it makes sense to have the same consistent naming convention

is it always

on

? Or are other prepositions admissable? For example, I have a

startLaterAction

currently, changing that to

onStartLater

makes a little less sense (to me) than

whenStartLater

how do you trigger that? Could it be

onStartLaterClick

maybe?

sometimes that works. some "actions" might be passed and triggered by both clicks and other interactions

I use on* everywhere, keeps it consistent. I also work on some React projects and see the same thing. I find the consistency makes it easy to scan code and get the gist of the flow

One thing that I do often for screen-level composables is pass in lambdas that do navigation events, and those have always felt a tiny bit weird to be

on*

. Like we got a chat feature, and often I name that

navigateToChat: () -> Unit

and it feels quite natural. But seeing this thread it does make me wonder that maybe I should just go ahead and start using

onNavigateToChat: () -> Unit

. Consistency is a good thing in general, but I haven’t convinced myself yet 😄

> onNavigateToChat Did the user actually navigate to chat, or did they press some button or performed some other action, and some higher level component (ViewModel) decided to navigate in response?

onSubmitClick

vs

sendRequest

onChatButtonClick

vs

navigateToChat

telling the ViewModel what event happened vs telling the ViewModel what to do

It’s not going towards the ViewModel at all. It’s exactly the same pattern as shown here, where the androidx.navigation part determines what the navigation actually means, and the composable itself just knows that it wants to navigate, doesn’t know how that actually happens. Surely it can be

onSubmitClick

but then good luck understanding 5 composables down what the button click even means.

Sure, ViewModel was just an example. > Surely it can be

onSubmitClick

but then good luck understanding 5 composables down what the button click even means. That sounds like a good thing. When I reuse the Composable later and the button does something else, or change the behaviour so it navigates to a confirmation screen instead of sending the request, then that’s all details that the Composable doesn’t need to know about. At that level of abstraction the submit button was clicked, what happens due to that is not it’s concern.

Obviously the designs sytem composable will just get a generic

onClick

. The screen-specific composable, which is

private

and won’t be used anywhere else, which has a hard-coded svg icon which is of a chat, will never do anything else 😄

Maybe your user needs to log in to be able to use the chat feature, and so the chat button actually navigates to the login screen if they are not logged in, etc.

Maybe your user needs to log in to be able to use the chat feature, and so the chat button actually navigates to the login screen, etc.

That’s solved on a different place anyway. The navigation to chat would happen, then the chat would figure out that they are logged out, and do the proper navigation. Just like a deep link to the chat would function the same exact way.

Maybe you need to add sending an analytics event when that button is pressed in addition to navigating to the chat screen, suddenly it’s not really navigateToChat because it also does that in addition to the navigation.

The analytics can go as a OnDestinationChangedListener on the NavController

That would count navigation, not button clicks (which in my imaginary app may result in going to a login screen instead).

Yeah, but I am answering like this because those scenarios don’t apply to us 😅 Also as I said before, navigation shouldn’t be conditional on the login state like that, otherwise it will become a mess having to check this in more or less the entire app. And even if you do, then a deep link comes in and you would need to solve that in a different way anyway. I get what you mean, and I do support that idea for reusable components too. But when they are not reusable and are literally file

private

, the indirection of naming them

onButtonClick

and then wondering what it does really has been a net negative in my experience.

Yep, all depends on the project and the specific code in question.