For those who didnt understand, this video is about not using trailing lambdas (when you have a composable, with the last parameter being an invokable runnable, then you can simply type it in a trailing lambda instead of explicitly typing it as a parameter) This will confuse others who read your code because they will think its some Composable function and not a NORMAL function This is merely for code readability purposes
A general thing I always teach is - "Imagine someone without using an IDE or advanced editor looks at this code." So make it as clear as possible - like always writing named parameters - to see what is going on
Just because some guy slacks off and not reviews MR properly noone should suffer. As long as IDE with all code services exists, it is a crime to force people to write code like if they in 1980s
So in short, Rule #1: With @Compose, we should avoid using non composable trailing lambda expressions outside of parentheses, since that's the usual place for composable content functions. Also it is better to use named parameters to make it clear. It looks reasonable.
it's more like a kotlin mistake... I like to use named stuff all the time to avoid any mistake as a rule of thumb I don't really think too much about it.
For those who didnt understand, this video is about not using trailing lambdas (when you have a composable, with the last parameter being an invokable runnable, then you can simply type it in a trailing lambda instead of explicitly typing it as a parameter)
This will confuse others who read your code because they will think its some Composable function and not a NORMAL function
This is merely for code readability purposes
A general thing I always teach is - "Imagine someone without using an IDE or advanced editor looks at this code." So make it as clear as possible - like always writing named parameters - to see what is going on
Just because some guy slacks off and not reviews MR properly noone should suffer. As long as IDE with all code services exists, it is a crime to force people to write code like if they in 1980s
@@the_wooffor a start, you don't get IDE hints looking at the Git diffs (even on GitHub and the like)
One the best things introduce by kotlin in general, not just for Compose
I do this because I often forget what the parameter was,, so I always use named parameter so can tell by just looking at the function call.
Exactly - and its no extra work at all - you write it once and profit every time you see it
Tip: You can easily move the lambda argument into the parentheses by just pressing Alt+Enter and selecting this refactoring from the menu 😊
😂😂 and I proudly been doing this all over the place
Thanks Phillip
Bro.. just increase the volume when you edit your shorts 😅 It's relatively lower than other youtube videos. Love your vids btw ❤
So in short, Rule #1:
With @Compose, we should avoid using non composable trailing lambda expressions outside of parentheses, since that's the usual place for composable content functions. Also it is better to use named parameters to make it clear.
It looks reasonable.
content, not context :)
@@vibovitold fixed. thanx!
Thank you! 👍
Great tip
Hey Philips, can you do comparation how fast you designing with Jetpack Compose vs XML pleasee 😊
I do that and usually advise ppl in my team to do that too, I thought it was a me thing, apparently more people agree, thanks u guys 😂
Why do we always use a :: for a viewmodel plz
it's more like a kotlin mistake... I like to use named stuff all the time to avoid any mistake as a rule of thumb I don't really think too much about it.
but thx
😮
I think this is the first i didn't understand what the hell are you saying! 😅😅
So avoid trailing lambdas?
in composable functions only because normally the trailing lambda is used to declare another inner composable