Do y'all really put modifiers "in the middle"? I f...
# compose
u
Do y'all really put modifiers "in the middle"? I find this recommendation by google rather strange. I doesn't then allow me to build up a eye-muscle memory as where to expect it
👌 8
s
It's the first optional parameter. Not "in the middle"
u
well, what I meant is not stable in position
s
Yeah it's quite stably after the last required parameter 😅
😂 4
☝️ 8
☝🏾 1
m
Over time, often arguments will switch between being required or not and so will have to jump around in the arg list to follow this recommendation. One really annoying one is where there is a required
onClick
and a non-required
onLongClick
, and so they won’t sit next to each other.
t
The function parameters order does not enforce anything on the caller side if you used named arguments (That should always be used to avoid issues anyway). I personally always do XX(state if present, modifier if needed, then the rest of the params)
a
I only care about consumers of my APIs (dont care about my inconvinience of ordering) and I ended up getting used to the order Stylianos mentioned. the order is used all accross foundation and if you don't follow it your API just stands out as odd
forcing the caller to use named parameters is not really ergonomic for commonly used components ie
Text
imagine if you were forced to always write
Text(text="content")
instead of just
Text("content")
u
I actually do name params and its nice.. imagine having unnamed click lambdas.. you have no idea what it is
a
i use named params for the same reason, but that is about how you choose to use apis. the discussion is about writing apis
t
For the record I follow it, I just said that the order is not enforced on consumer side (the order I gave as example was client side) so you can have click and optionallong click nearby at client side. And there I also try to keep a convention to help reading.