Marc Knaup
11/30/2020, 12:33 PMequals()
implementation for lambdas.
Button(
label = "Print count",
onClick = @Equatable { println(count) }
)
data class ButtonProps(val label: String, val onClick: () -> Unit)
That’s useful in Kotlin React development and similar. If the props (arguments) of a component are equal between two rendering attempts then the second rendering can be skipped (memoization). Unfortunately that doesn’t work if the props contain lambdas because they’ll never be equal to the previous instance.
React provides a workaround like val onClick = useCallback(count) { println(count) }
which only uses the passed instance of the lambda if count
has changed and the previous one otherwise. This is more boilerplate and you have to move the lambda further away from where it’s actually used. More importantly it easily leads to errors where you forget to add a dependency (a bound variable) and therefor an old function with different variable bindings will be used.
@Equatable
could tell the compiler to generate an equals
method for that lambda which compares all bound variables automatically - in this case count
. That would solve the issue and eliminate that cause of errors.Dominaezzz
11/30/2020, 6:08 PMfun interface
so it shouldn't be hard to do for lambdas.Marc Knaup
11/30/2020, 6:09 PMfun interface
? 😮
Do you have a link with further info?Dominaezzz
11/30/2020, 6:12 PMMarc Knaup
11/30/2020, 6:15 PMYoussef Shoaib [MOD]
01/19/2021, 3:04 PMfun interface EquitableLambda
and make every react function use that instead of the normal lambda typesMarc Knaup
01/19/2021, 3:10 PMEquatable
, not on the side where React expects a function.
Whether a lambda can be made equatable in any meaningful way and without causing negative side-effects can only be determined at the call site.
What we could do is to allow @Equatable
on both sides.
The call site makes the compiler implement equals
.
The callee site makes the compiler issue a warning if the lambda passed to such a parameter is not marked @Equatable
.