I am trying to do

Input

component with

Modifiers

and I am struggling a little. Is there easier way to do this?

@Composable
fun MyTextField(
    value: String,
    onValueChange: (String) -> Unit,
    type: InputType<String> = InputType.Text,
) {
    Input(
        type = type,
        attrs = Modifier
            .attrsModifier(inputAttrs(value, onValueChange) as AttrsScope<*>.() -> Unit)
            .toAttrs()
    )
}

private fun inputAttrs(
    value: String,
    onValueChange: (String) -> Unit
): InputAttrsScope<String>.() -> Unit = {
    value(value)
    onInput { onValueChange(it.value) }
}

I eventually want to create a Silk input widget! But you can take a look at

kobweb create examples/chat

for some examples of how I'm wrapping inputs in my own code.

ooooh! I din't realize I can just call

toAttrs

and pass a extension lambda. That makes sense

Ah! Sorry I missed that! Yes, it can occasionally be very convenient.

Would you consider adding "typed"

attrsModifier

, (instead of

AttrsScope<*>

) for similar usecases? Does that even make sense?

My apologies, I'm not following. Can you give a concrete example?

Maybe it does not make sense but the use case is my original question.

attrsModifier

lamda has

AttrsScope<*>.() -> Unit

signature so I cannot access functions of specific attr scope (like

InputAttrsScope

in the example). The only way to add is with

toAttrs {}

which is "typed" to attr scope of the element it is applied to

Ah the problem there is chaining I think

Yeah, maybe it's bad idea to enable this in general 😅 It was just the first thing that came into my head when trying to implement custom

Input

No worries, it's definitely an awkward part of kobweb

Yeah but the modifier system is android friendly so I appreciate it. Even though you advise against in-line modifiers in favour of styles.

Honestly, I'm still exploring what best practices are! In kobweb, inline styles may actually be easier to use in many cases, and unlike css, you have kotlin's type system to help you

The main disadvantage for me is that I can't pass parameters to them and must create variants. I am just so used to the Android world where everything can be tweaked with change of one parameter. Bu I guess this is the "web" way of doing this.

Silk widgets will try to look more like Android widgets (I think)

But I feel like that goes agains the idea of styles 😕 I am trying to make clear boundaries for me of what to put into style and what to put into parameter but I am still lost rn

Styles, even in Compose, are global

But in web context the styles are not just colors and shapes. It's also border, font, animations etc.. So the parallel does not really work for me. Also modifiers in "Skia Compose" are more of a decorator rather than attributes so order matters.

Yeah, that's true

Yes, that works but that does not answer my "ComponentStyle vs Inline" approach. I still don't see the line of when to use what but that might be just my inexperience with web technologies

Oh yeah, that's fair. I don't think there's a right answer there

I don't think there's a right answer there

Exactly and there are a few problems I face • migrating from one approach to another is not straight forward because of need of migrating function parameters into component variants • you cannot easily combine both of them. I mean technically you can but from UI component design perspective it's not easy task • you have to use styles for pseudo elements/selectors

Yes, pseudo selectors too, that's right

I mean API design

Maybe I need to create a Kobweb IntelliJ plugin to help with refactoring 😄

Maybe in future that would be nice :D

API design, all silk widgets take a Modifier and a variant, then internally call: Style.toModifier(variant).then(modifier)

API design, all silk widgets take a Modifier and a variant

Yeah I do the same with my components. Let's see how it works out

I think that's perfect! You shouldn't get in trouble with that approach

My problem with it is that it's not transparent. But again, maybe that's just my inexperience with web development

I suspect webdevs have to learn this distinction too

I'm happy to hear how you feel about it over time

Don't you worry about that. I like talking about code and code design 😄 So I think this is not our last 50+ message thread