About state hoisting, I have two questions: - When we build a simple screen, there will be a few sta...

# compose

[Tlaster]

About state hoisting, I have two questions:
• When we build a simple screen, there will be a few states and few onValueChange, but when we build a complex screen, we will get a lot of states and lots of onValueChange , there will be many parameters for the composable method, is there any optimization we can do to reduce the parameters?
• If we have onValueChange inside a very deep composable, it will pass all the way up to the top screen to actually handle the onValueChange , is there a better way to do it instead of passing it all the way up to the top screen?

[Filip Wiesner]

1. Try building state objects like TextFieldValue which groups several onChange candidates together (in this case text, selection and composition) but this one is hard to answer without context.
2. This problem can be partly solved by using the "slot pattern" so you don't pass the lambda down the tree through parameters.
Leland Richardson talks about it in his "Thinking in Compose" video (somewhere around 9:30 mark)

[Tlaster]

Thanks! I might need to rethink how to construct Compose application.