Блог

Когда мы говорим о Compose, мы обязательно столкнемся с подходом подъема состояния. Что довольно удобно и не требует знаний в области ракетостроения. Но здесь вступает в игру куча других вопросов и еще куча возможных решений. Это все о многочисленных параметрах, проходящих через объявление fun. Возвращаясь к старым добрым временам, мы могли бы позволить себе иметь контейнер, который будет содержать в основном все параметры (простой). С другой стороны, у нас могут быть параметры по умолчанию, но в любом случае это не поможет справиться с несколькими (огромным количеством) строками объявления функции. Какие-нибудь мысли здесь?

Если мы погрузимся немного глубже и рассмотрим androidx.compose.*** (т. Е. Материальный) пакет, мы найдем множество составных элементов, которые на самом деле имеют много параметров (лямбд) для подъема состояния. Поэтому я считаю, что это общий подход. Мы можем взять TextField composable, что является хорошим примером того, что я говорю:

 @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)
)
  

Конечно, он также содержит множество параметров конфигурации и составных слотов.
Тем не менее, вопрос остается.
У меня есть несколько вариантов, когда такая ситуация может произойти:

• Сложный пользовательский интерфейс, состоящий из множества возможных пользовательских событий, т. Е. TextField
• Сложная структура / иерархия пользовательского интерфейса с несколькими составными элементами, которые обертывают друг друга и должны поднимать события / пользовательские данные снизу вверх. Ну, подъем может увеличить уровень параметров (лямбд) на каждом уровне.
• Your case here

PS Я не говорю, что это неправильно или в этом есть что-то плохое, просто пытаюсь найти удобный способ.

P.P.S. Я знаю, что все дело в компромиссах.

Лично я думаю, что структурирование параметров в data classes может дать немного больше удобства для чтения, для бота потребителя и поставщика.

Например: activeColor , inactiveColor , errorColor , backgroundColor . Может быть перемещен в

 data class TextFieldColors(
    val activeColor: Color, 
    val inactiveColor: Color, 
    val errorColor: Color, 
    val backgroundColor: Color)
  

(Прошу прощения за название здесь)

Вы могли бы сделать это аналогично для значков, заполнителей и в основном структурировать свои параметры таким образом, чтобы это имело смысл как для поставщика, так и для потребителя.

Кроме того, я считаю, что повторное использование этих уже созданных классов параметров может помочь при расширении существующих компонентов.