Hey Matze - good video (liked and subscribed!). I particularly appreciate the discussion on #5 - I have never seen the lambda used to solve this problem.
@@kapps7407 In some other tutorials, the author might attempt to pass the MutableState into the subcomposable but I don't like this since it complicates the sub, plus allows the sub to modify the value. So I was proud to pass the *mutable.value* pure text into the sub-composable. I didn't realize that was sub-optimal until you pointed it out. Using a lambda seems like a third option (1- pass the Mutable, 2- pass Mutable.value, 3 - use a lambda as you suggest).
@@kapps7407 Oh hey --- I need to try this, but if you had used "var count *by* remember { mutableStateOf(0) }" then you would not have to use .value -- I doubt it changes anything since the delegation will probably still call *value* behind the scenes...
Passing state down to your sub composable if you are just interested in the value T from the state is never a good idea. Then you can't reuse your Composable if you have just the value T and no State Interface wrapped around it. I mean passing down Mutable.value is also fine if you don't have that much in your parent Composable. It should always be done carefully tho.
Yes BY remember is the delegating version. Under the hood there is a defined operator function getValue() which directly accesses the state.value for you. But yes it does not solve the problem with parent recomposition as you already pointed out.
Thanks for sharing. However, for the tip #5, I believe Composable2 is not recomposed even before Composable1 is optimized. This fun is marked as skippable because it receives an immutable (primitive type) parameter. Here, because the value of its parameter remains the same, this fun is skipped when Column is re-executed on recomposition.
I have 2 questions regarding last point (passing lambdas instead of state values). 1. Would the problem also exist if we wouldn't read the value in parent composable to create a strings out of it, but pass it as it was? 2. Is there any downside of this solution? If not, shouldn't we strictly always use this method, when passing state's parts to children composables?
1. For the example in the video: If you would do it like this then you would also prevent the parent composable from recomposition. But it is not a good practice to pass a State value down to a child composable. The child composable is only there to display a String and not to read state. Imagine if you want to reuse this composable at some other place in your app and you would only have a String then you could not invoke the child composable. 2. The downside is that you have to write more code with this lambdas. For the best performance you should do this every time. But if you have almost no other composables or calculations in your parent composable then you could also read the state one level higher if you don't want to write that much lambdas.
Many thanks for sharing your knowledge. All the best!
Thank you!
your channel content is wonderful. wish you will make new ones ❤
keep up, man!
Great content!
Hey Matze - good video (liked and subscribed!). I particularly appreciate the discussion on #5 - I have never seen the lambda used to solve this problem.
Thank you Mike, appreciated! How did you solve this problem so far or didn't you take care that much?
@@kapps7407 In some other tutorials, the author might attempt to pass the MutableState into the subcomposable but I don't like this since it complicates the sub, plus allows the sub to modify the value. So I was proud to pass the *mutable.value* pure text into the sub-composable. I didn't realize that was sub-optimal until you pointed it out. Using a lambda seems like a third option (1- pass the Mutable, 2- pass Mutable.value, 3 - use a lambda as you suggest).
@@kapps7407 Oh hey --- I need to try this, but if you had used "var count *by* remember { mutableStateOf(0) }" then you would not have to use .value -- I doubt it changes anything since the delegation will probably still call *value* behind the scenes...
Passing state down to your sub composable if you are just interested in the value T from the state is never a good idea. Then you can't reuse your Composable if you have just the value T and no State Interface wrapped around it. I mean passing down Mutable.value is also fine if you don't have that much in your parent Composable. It should always be done carefully tho.
Yes BY remember is the delegating version. Under the hood there is a defined operator function getValue() which directly accesses the state.value for you. But yes it does not solve the problem with parent recomposition as you already pointed out.
Thanks for sharing. However, for the tip #5, I believe Composable2 is not recomposed even before Composable1 is optimized. This fun is marked as skippable because it receives an immutable (primitive type) parameter. Here, because the value of its parameter remains the same, this fun is skipped when Column is re-executed on recomposition.
Hey matze, how can we avoid MATHJVM nan issues coming from compose libs and has no consumer code traces, please help🎉
I have 2 questions regarding last point (passing lambdas instead of state values).
1. Would the problem also exist if we wouldn't read the value in parent composable to create a strings out of it, but pass it as it was?
2. Is there any downside of this solution? If not, shouldn't we strictly always use this method, when passing state's parts to children composables?
1. For the example in the video: If you would do it like this then you would also prevent the parent composable from recomposition. But it is not a good practice to pass a State value down to a child composable. The child composable is only there to display a String and not to read state. Imagine if you want to reuse this composable at some other place in your app and you would only have a String then you could not invoke the child composable.
2. The downside is that you have to write more code with this lambdas. For the best performance you should do this every time. But if you have almost no other composables or calculations in your parent composable then you could also read the state one level higher if you don't want to write that much lambdas.