https://kotlinlang.org
Join Slack
For closure actions that get passed to @Composables, I'm finding I go back and forth between paramet...
# compose
t
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
1st party APIs that ship with compose itself stuck to 
on*
names
f
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
So is that an argument to "when in rome" or to do the alternate so as to distinguish own code from 1st party?
f
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
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
how do you trigger that? Could it be 
onStartLaterClick
maybe?
t
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
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
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
> 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
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
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
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
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
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
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
The analytics can go as a OnDestinationChangedListener on the NavController
m
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
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
Yep, all depends on the project and the specific code in question.
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by