• d

    darkmoon_uk

    1 year ago
    To fully use 'multiplatform widgets' we currently need to use the word web:
    implementation(compose.web.widgets)
    ...in common code. The underlying string is also web-specific, being:
    org.jetbrains.compose.web:web-widgets:0.5.0-build224
    I hope it's only like this during development phase as it's counter-intuitive. Is there a plan to bring these into a truly common namespace/artifact?
    d
    olonho
    2 replies
    Copy to Clipboard
  • hfhbd

    hfhbd

    1 year ago
    I did not find a typed routing library, so I implemented one by myself. Any feedback is welcome! https://github.com/hfhbd/routing-compose
    hfhbd
    Ryan Brooks
    2 replies
    Copy to Clipboard
  • Sam

    Sam

    1 year ago
    I’m trying to read Input’s value on input change like this:
    Input(type = InputType.Text, attrs = {
        onInput {
            console.log(it.nativeEvent.target.asDynamic().value)
        }
    })
    Is there a more elegant/safe way of doing it (alternative to
    WrappedInputEvent.nativeEvent.target.asDynamic().value
    )?
    Sam
    [JB] Shagen
    2 replies
    Copy to Clipboard
  • theapache64

    theapache64

    1 year ago
    theapache64
    Big Chungus
    +1
    9 replies
    Copy to Clipboard
  • spierce7

    spierce7

    1 year ago
    A good amount of the work has already been done to optimize compose at the common / compiler level already. I realize performance hasn’t been considered yet from the web / js perspective, but I wonder how good the performance of compose web would be when compared against react when using plain HTML dom components.
    spierce7
    than_
    2 replies
    Copy to Clipboard
  • j

    jw

    1 year ago
    not doing a virtual dom should already place it far ahead. a more interesting comparison would be svelte
    j
    1 replies
    Copy to Clipboard
  • Colton Idle

    Colton Idle

    1 year ago
    React noob and compose noob here so sorry if this comes off as stupid, but am I understand what jake said correctly? Compose for web should be "better" perf wise than react because it doesn't use a virtual dom? Isn't the concept of the virtual dom close to composes tree where it "diffs" things?
    Colton Idle
    spierce7
    +2
    5 replies
    Copy to Clipboard
  • Colton Idle

    Colton Idle

    1 year ago
    I have no reason/excuse to use compose for web yet... but this week I'm getting started on a chrome extension... and so I get to use compose for web! Thanks @theapache64
    Colton Idle
    1 replies
    Copy to Clipboard
  • d

    darkmoon_uk

    1 year ago
    Is there any compelling reason for web/common to use a different Color representation to Android/Desktop? (
    value class / ULong
    vs
    data class RGB Hex
    ); this only makes the two worlds harder to bridge, and there aren't any ready conversion functions that I can see. Couldn't all the color code standardize on
    ULong
    , and the common Color disclose an Android/Desktop color via
    .implementation
    ?
    d
    3 replies
    Copy to Clipboard
  • theapache64

    theapache64

    1 year ago
    RESOLVED:🔥 Do we have hot reload in compose-web?
    theapache64
    solidogen
    +1
    11 replies
    Copy to Clipboard