In Jetpack Compose, it's common to pass lambda fun...
# compose-android
k
In Jetpack Compose, it's common to pass lambda functions as parameters in both stateful and stateless composables. I'm considering using interfaces for this purpose instead and would like to understand the implications of this approach.
1. Is using interfaces instead of lambda functions in this context against Jetpack Compose guidelines or best practices? 2. What are the potential drawbacks of using interfaces in place of lambda functions for passing callbacks or other functional parameters in Composables? Simple example:interface
Copy code
MyComposableCallback {
    fun onEventOccurred(data: String)
}

@Composable
fun MyComposable(callback: MyComposableCallback) {
    // Composable implementation
}

// Usage
val myCallback = object : MyComposableCallback {
    override fun onEventOccurred(data: String) {
        // Handle event
    }
}

MyComposable(callback = myCallback)
As opposed to the more conventional lambda approach:
Copy code
@Composable
fun MyComposable(onEventOccurred: (String) -> Unit) {
    // Composable implementation
}

// Usage
MyComposable { data ->
    // Handle event
}
Any insights on the pros and cons of each approach in terms of performance, readability, and adherence to Compose principles would be greatly appreciated.
p
I'm not answering your question, just a small hint to add here: Are you aware of
fun interface
-> https://kotlinlang.org/docs/fun-interfaces.html ? I think this would allow you to have an additional variant to the two approaches you mentioned above.
k
Thanks @p-schneider for answering me. I don't know about the
fun interface.
Actually I prefer to use lambda but some of my friends are saying we don't need to pass the lambda function we can use the interface. So I just want pros and cons using the interface.
a
I'd say the most important thing is to profile the two options and make sure you aren't adding to your recomposition count
k
Sorry what do you mean in recomposition count?
473 Views