https://kotlinlang.org logo
#compose
Title
# compose
t

Travis Griggs

11/06/2023, 9:02 PM
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
1️⃣ 7
z

Zach Klippenstein (he/him) [MOD]

11/06/2023, 9:11 PM
1st party APIs that ship with compose itself stuck to
on*
names
f

Francesc

11/06/2023, 9:13 PM
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
t

Travis Griggs

11/06/2023, 9:13 PM
So is that an argument to "when in rome" or to do the alternate so as to distinguish own code from 1st party?
f

Francesc

11/06/2023, 9:15 PM
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
t

Travis Griggs

11/06/2023, 9:21 PM
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
f

Francesc

11/06/2023, 9:28 PM
how do you trigger that? Could it be
onStartLaterClick
maybe?
t

Travis Griggs

11/06/2023, 9:30 PM
sometimes that works. some "actions" might be passed and triggered by both clicks and other interactions
I'm finding that sometimes my "god" composables (the top level ones where the rootiest state lives, have to pass a bunch of closures downward, because only at the root level does the logic live to combine the different peices. For examble actions for navigation.
c

Chris Fillmore

11/07/2023, 12:19 AM
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
🙏 1
s

Stylianos Gakis

11/08/2023, 2:32 PM
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 😄
Saying that, looking for the official docs https://developer.android.com/guide/navigation/use-graph/navigate#navigate-example I immediately end up finding this place where they also name it
onNavigateToFriends
, which proves that I am undecided for no reason I think 😄
m

Marcin Wisniowski

11/09/2023, 12:35 PM
> 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
s

Stylianos Gakis

11/09/2023, 12:39 PM
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.
m

Marcin Wisniowski

11/09/2023, 12:43 PM
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.
s

Stylianos Gakis

11/09/2023, 12:44 PM
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 😄
m

Marcin Wisniowski

11/09/2023, 12:44 PM
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.
s

Stylianos Gakis

11/09/2023, 12:46 PM
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.
m

Marcin Wisniowski

11/09/2023, 12:47 PM
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.
That’s solved on a different place anyway.
Sure, I don’t question the naming works perfectly fine for you, just thinking about some what ifs that make me use the naming I use.
s

Stylianos Gakis

11/09/2023, 12:49 PM
The analytics can go as a OnDestinationChangedListener on the NavController
m

Marcin Wisniowski

11/09/2023, 12:52 PM
That would count navigation, not button clicks (which in my imaginary app may result in going to a login screen instead).
But yes you can solve every example I bring up differently, my point is just that handling an UI event might change, and how the UI event is handled is not the concern of the UI, hence naming the callbacks after the UI event, not the handling, seems better to me.
s

Stylianos Gakis

11/09/2023, 12:56 PM
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.
m

Marcin Wisniowski

11/09/2023, 1:00 PM
Yep, all depends on the project and the specific code in question.
2 Views