I’m not happy with `kotlin-react` and `kotlinx-htm...

# javascript

[Marc Knaup]

I’m not happy with kotlin-react and kotlinx-html, so I’ve started my own React wrapper.
• Similar to kotlin-react.
• Nicer and consistent API. Easier to use.
• Not multiplatform. Optimized for Kotlin/JS instead.
• No dependencies beside React [Router].
• Lower size and performance overhead.
• More type safety, esp. around hooks.
• Props allow class instead of just external interface.
• Highly experimental. IR compiler only. Relies on unofficial compiler behavior.

Anyone wants to join the project? 😄

https://github.com/fluidsonic/fluid-react

[Marc Knaup]

How the CSS library currently works:

[Marc Knaup]

Component example from my project

[andylamax]

While I am also not happy with kotlin-react I have no problems with kotlin-styled at all, its syntax was so concise.

I considering joining you i this one

[Big Chungus]

I'd love to help. Do you have some issues written up?

[andylamax]

looks like there is none at the moment

[andylamax]

I don't know performance wise but,

val PriceCard : RComponent<PriceCardProps> by react.component { props->
  // . . . 
}

looks so much better than

val Component:RComponent<PriceCardProps> = react.component("PriceCard"){props->
  // . . .
}

[Marc Knaup]

While I am also not happy with kotlin-react I have no problems with kotlin-styled at all, its syntax was so concise.

I  considering joining you i this one

Interesting. I was particularly unhappy with styled which is why I’ve written my own CSS library.

[Marc Knaup]

Best place to start contributing would be to add more HTML tags & attributes:
https://github.com/fluidsonic/fluid-react/tree/main/modules/dom/sources/js/html

And SVG:
https://github.com/fluidsonic/fluid-react/tree/main/modules/dom/sources/js/svg

[Marc Knaup]

val PriceCard : RComponent<PriceCardProps> by react.component { props->
  // . . . 
}

You can.
I don’t use that in my project for two reasons:

a) My components are private. I expose wrapper functions like this:

[Marc Knaup]

b) The String is used by React Debugging Tools to show the name of each component in the tree.

Performance-wise there’s no difference. The String isn’t included in production builds.

[Big Chungus]

Wouldn't it be better to copy what kotlinx.html does and generate all html tags from schema?

[Marc Knaup]

No. kotlinx-html targets pure HTML. There are several issues open for kotlin-react and kotlinx-html due to incompatibility with React.

React expects different casing for properties (DOM camel case instead of lowercase), different types (DOM types e.g. booleans, integers, etc.) and there are some React specifics (e.g. style being an object).
Given enough time it may be possible to write a generator, but I don’t think it’s worth it.

[christophsturm]

do you also plan a wrapper for react-testing-library?

[Marc Knaup]

I’ve never used that library. Nothing is planned for testing so far.

I’ve spent a lot of time on react and CSS libs so it’s time to finish the actual project built on top of it 😅

[andylamax]

In your part B, using delegates, you can assign the name of the component to be the variable name

[andylamax]

I think what @Big Chungus suggests is, generating the html tags from a schema. Not copying exact implementation from kotlinx-html

[Marc Knaup]

Yes, delegation could indeed make the name available. I completely read over the by in the suggestion 😄

But delegation adds quite some overhead. Also the name cannot be removed from production builds then – they’re only supposed to be used in debug builds.

[Marc Knaup]

But I can do some experiments if I find way to optimize that.

[Marc Knaup]

external & inline are like all-purpose optimization tools 🙂

[Marc Knaup]

Alright, I think I found a way to optimize it.
But every library user would have to set up optimization like this:

[andylamax]

elaborate please

[Marc Knaup]

The compiler generates weird stuff like the following, which is also included in production builds.
Using the Terser optimization settings from above the optimizer can then remove that garbage from production builds.

[Marc Knaup]

Alright, I’ve added component naming by delegation 🙂
https://github.com/fluidsonic/fluid-react/blob/c5efcc205e76560527cd98ff0ec4f243f264c470/modules/playground/sources/js/EmojiContainer.kt#L5

Thanks for the suggestion and sorry for the misunderstanding earlier.

The resulting code will be slightly less performance and larger in size.
That can be compensated by improving settings of the Webpack minification. I’ll add some advice on that later on.

[Björn Mayer]

Just recently I also started writing my own wrapper. I wanted to make use of the DslMarkers which is almost impossible with the current split between builder and components. Hence I came up with this:

rootDiv.reakt {
    +TestComponent(prop1 = "Test") {
        +TestComponent(prop1 = "Test3") {
            +Div("test4") {
                attrs {
                    id = "test"
                }
            }
        }
        +"Lol"
        +TestComponent()
    }
}

class TestComponent(
    prop1: String = "lol",
    handler: ReaktBase.ReaktHandler<TestComponent> = ReaktBase.ReaktHandler { }
) : Component<TestComponent, TestComponent.Props>(handler) {
  ...
}

It’s neither working yet, nor is it commited somewhere. And I am not sure if I want to follow this path.
Seeing your project gives me hope though, that we will have a nice to use dsl for react in kotlin.

[Big Chungus]

DSL markers are great!