Filip Wiesner
04/18/2022, 1:51 PM@Composable
function when you ask yourself "should I divide this into separate composables/files"?
1️⃣ 50 lines
2️⃣ 100 lines
3️⃣ 200 lines
4️⃣ 300 lines
5️⃣ It's not dependant on number of lines but rather number and cohesion of parameters
6️⃣ It's fine as long it does "one thing".
7️⃣ Other 👉 commentFilip Wiesner
04/18/2022, 2:51 PMgildor
04/18/2022, 3:14 PMZach Klippenstein (he/him) [MOD]
04/18/2022, 4:35 PMFilip Wiesner
04/18/2022, 4:41 PMZach Klippenstein (he/him) [MOD]
04/18/2022, 4:44 PMFilip Wiesner
04/18/2022, 4:47 PMZach Klippenstein (he/him) [MOD]
04/18/2022, 4:49 PM}
?Filip Wiesner
04/18/2022, 4:51 PMAdam Powell
04/18/2022, 6:36 PMdewildte
04/18/2022, 6:36 PMdewildte
04/18/2022, 6:37 PMAdam Powell
04/18/2022, 6:39 PMAdam Powell
04/18/2022, 6:40 PMdewildte
04/18/2022, 6:41 PMdata class
that contains the state.Adam Powell
04/18/2022, 6:42 PMdewildte
04/18/2022, 6:43 PMAdam Powell
04/18/2022, 6:43 PMAdam Powell
04/18/2022, 6:43 PMText
dewildte
04/18/2022, 6:44 PMAdam Powell
04/18/2022, 6:44 PMdewildte
04/18/2022, 6:44 PMAdam Powell
04/18/2022, 6:44 PMAdam Powell
04/18/2022, 6:44 PM[Mutable]State<T>
in a parameter listAdam Powell
04/18/2022, 6:45 PMgetFoo: () -> Foo
is always going to be a more flexible parameter than foo: State<Foo>
Adam Powell
04/18/2022, 6:46 PMAdam Powell
04/18/2022, 6:46 PMTash
04/18/2022, 8:48 PMoh! Adam, could you elaborate on this a bit more? I feel like I kinda understand why, but a little unsure. Is it becauseis always going to be a more flexible parameter thangetFoo: () -> Foo
foo: State<Foo>
[Mutable]State<T>
as a param to a composable is akin to having a var list = mutableListOf()
i.e. two degrees of mutability?Adam Powell
04/18/2022, 8:54 PM@Composable
fun SomeComposable(state: State<MyType>)
Happy path:
val myState = remember { mutableStateOf(initial) }
SomeComposable(myState)
Broken property delegation; wrapper needed:
var myState by remember { mutableStateOf(initial) }
SomeComposable(
object : State<MyType> {
override val value: MyType get() = myState
}
}
Broken aggregation into a single source of truth:
class SomeParentState {
var thing by mutableStateOf(...)
private set
}
@Composable
fun Caller(parentState: SomeParentState) {
SomeComposable(
object : State<MyType> {
override val value: MyType get() = parentState.thing
}
)
}
Adam Powell
04/18/2022, 8:56 PM@Composable
fun SomeComposable(getState: () -> MyType)
No property delegation:
val myState = remember { mutableStateOf(initial) }
SomeComposable { myState.value }
With property delegation:
var myState by remember { mutableStateOf(initial) }
SomeComposable { myState }
Aggregation into a single source of truth:
class SomeParentState {
var thing by mutableStateOf(...)
private set
}
@Composable
fun Caller(parentState: SomeParentState) {
SomeComposable { parentState.thing }
}
Tash
04/18/2022, 8:56 PMBroken aggregation into a single source of truth:ack! 😖
Tash
04/18/2022, 8:57 PMAdam Powell
04/18/2022, 8:58 PM[Mutable]State<T>
as parameters or as public properties of a type; both lead to these kinds of pathologiesAdam Powell
04/18/2022, 8:59 PMTash
04/18/2022, 9:00 PMgetFoo: () -> Unit
is more one the nose for what you might be trying to do anywayAdam Powell
04/18/2022, 9:01 PMFilip Wiesner
04/19/2022, 6:32 AMIt’s hard to offer much advice with out understanding your code more intimately though.Thank you but I wasn't really looking for advice 😅 I was just interested in other people opinion on this and to be honest I didn't expect so many people are fine with having big composable function as long as they do "one thing" (whatever that means). Whenever I have 150+ LOC long composable I start actively looking how to divide it because it feels really weird and cumbersome. Even if it does one thing, e.g. Screen component that just puts together other parts. Thanks everyone who voted and/or explained their opinion in comments ♥️
dewildte
04/19/2022, 3:21 PMFilip Wiesner
04/19/2022, 4:08 PMAdam Powell
04/19/2022, 5:22 PMAdam Powell
04/19/2022, 5:22 PM