在谈论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
Your case here
P.S。我并不是说这是错误的或有坏处,只是试图找到一种舒适的方法。
P.P.S。我知道这全都与权衡有关。
答案 0 :(得分:1)
我个人认为,将参数结构化为data classes
可以为机器人消费者和提供者提供更高的可读性。
例如:activeColor
,inactiveColor
,errorColor
,backgroundColor
。可以移到一个
data class TextFieldColors(
val activeColor: Color,
val inactiveColor: Color,
val errorColor: Color,
val backgroundColor: Color)
(请在这里命名)
您可以类似地对图标,占位符执行此操作,并且基本上以对提供商和使用者都有意义的方式来构造参数。
此外,我相信重用这些已经创建的 Parameter类在扩展现有组件时会有所帮助。