问题描述
在谈论Compose时，我们肯定会面对state hoisting的方法。这很舒服，不需要火箭科学知识。但是这里涉及其他问题以及其他可能的解决方案。这就是通过fun声明传递的众多参数的全部。回到过去的美好时光，我们可以允许我们自己拥有一个容纳大部分参数（简单参数）的容器。另一方面，我们可以具有默认参数，但是在任何情况下都无助于处理多行（大量）函数声明。这里有什么想法吗？
如果我们更深入地研究并回顾androidx.compose.***（材料）软件包，我们会发现许多实际上具有许多用于状态提升的参数（lambda）的可组合材料。因此，我认为这是一种常见的方法。
我们可以将TextField设为可组合，这是我所说的一个很好的例子：
@Composable
fun TextField(
value: String,onValueChange: (String) -> Unit,modifier: Modifier = Modifier,textStyle: TextStyle = AmbientTextStyle.current,label: @Composable (() -> Unit)? = null,placeholder: @Composable (() -> Unit)? = null,leadingIcon: @Composable (() -> Unit)? = null,trailingIcon: @Composable (() -> Unit)? = null,isErrorValue: Boolean = false,visualTransformation: VisualTransformation = VisualTransformation.None,keyboardType: KeyboardType = KeyboardType.Text,imeAction: ImeAction = ImeAction.Unspecified,onImeActionPerformed: (ImeAction,SoftwareKeyboardController?) -> Unit = { _,_ -> },onTextInputStarted: (SoftwareKeyboardController) -> Unit = {},interactionState: InteractionState = remember { InteractionState() },activeColor: Color = MaterialTheme.colors.primary,inactiveColor: Color = MaterialTheme.colors.onSurface,errorColor: Color = MaterialTheme.colors.error,backgroundColor: Color = MaterialTheme.colors.onSurface.copy(alpha = ContainerAlpha),shape: Shape =
MaterialTheme.shapes.small.copy(bottomLeft = ZeroCornerSize,bottomright = ZeroCornerSize)
)
当然，它还包含许多配置参数和composable slots。 尽管如此，问题仍然存在。 当发生这种情况时，我几乎没有选择：
- 由许多可能的用户事件（即
TextField组成的复杂UI）
- 一个复杂的UI结构/层次结构，具有多个相互组合的可组合项，需要从下到上提升事件/用户输入。好吧，吊装可以在每个级别上增加参数（lambda）级别。
-
Your case here
P.S。我并不是说这是错误的或有坏处，只是试图找到一种舒适的方法。
P.P.S。我知道这全都与权衡有关。
解决方法
我个人认为，将参数结构化为data classes可以为机器人消费者和提供者提供更高的可读性。
例如：activeColor，inactiveColor，errorColor，backgroundColor。可以移到一个
data class TextFieldColors(
val activeColor: Color,val inactiveColor: Color,val errorColor: Color,val backgroundColor: Color)
（请在这里命名）
您可以类似地对图标，占位符执行此操作，并且基本上以对提供商和使用者都有意义的方式来构造参数。
此外，我相信重用这些已经创建的 Parameter类在扩展现有组件时会有所帮助。