hey, i am currently experimenting with a react app...

# javascript

[Christian Dräger]

hey, i am currently experimenting with a react app written in kotlinjs.
i’m wondering how to use npm dependencies that are extending react functionality and how this plays together when using the kotlin-react wrapper provided by jetbrains.
for instance i want to use this lib https://fkhadra.github.io/react-toastify/introduction i use a lot in react projects without kotlin and can confirm it works great and out of the box. the lib is completely written in typescript. so i would expect dukat to generate externals propperly when adding

implementation(npm(name = "react-toastify", version = "6.0.8", generateExternals = true))

to my build gradle. and it actually does but i am wondering how to use the generated externals.
The libraries documentation says <ToastContainer …props /> has to be added to the apps JSX code. in my generated externals i found a useToastContainer
function in the generated externals (see screenshot). no extension function to RBuilder or something that looks like i can just use it straight away

questions:
is there a naming convention that dukat uses to place the public functions of a dependency like prefixing the file that includes the api of a library with ‘use….’ ? if not, where are the public functions of library placed that has a dukat generated kotlin wrapper?

do i need to write an extension function to RBuilder like `fun RBuilder.toastContainer() = useToastContainer()`to use it with kotlin react wrapper?

useToastContainer wants ToastContainerProps which is an interface regarding to the generated externals i couldn’t find an implementation of that interface. I would assume an implementation with default values like the original lib has. so im wondering how to use this or do i have to implement it myself (would be extremely unhandy since it has a lot of props) ?

what experiences do you have using libraries that extend react in kotlinjs?

[Joffrey]

Hi @Christian Dräger, I have had quite a bit of trouble understanding how to use typescript react component libraries in Kotlin/JS, so I’ll try to show you what I did. I was using blueprintjs myself in a react project that I converted to Kotlin-React.

I share a bunch of your questions, so I won’t be able to answer them myself, but at least I can answer one: I had to write some RBuilder extensions by hand to make the lib convenient to use in a Kotlin-React context. However I didn’t have to write the props interface implementation (you can use attrs { … } to just “set” properties), but I did need to set default values by hand in the RBuilder extensions.
If you want to take a look at some examples, here are some links to the project where I did this:
• the file declaring RBuilder extensions by hand, using child() with the component’s class as parameter
• the package where I sort of generated the typescript declaration with Dukat (a while ago), but be aware that I had to fix all of them manually, and I think it deviates quite a lot from what Dukat would generate now
Note that this information might be outdated, as I did this a few months back and it might have changed a lot in the meantime (for instance “generate externals” was experimental at the time).

[Christian Dräger]

Ok I see. The declaration of rbuilder extensions example helps a lot.

[Joffrey]

I don’t think the way I did this is ideal though (not very maintainable to have all this manual work). So I’m trying to figure out if I can generate this on top of Dukat’s generated code.
I believe this RBuilder extension stuff is really specific to Kotlin-react, so I don’t think it has its place in Dukat itself, and I don’t believe it will be implemented there. I don’t know what the next versions of Dukat have to offer though, maybe I should just be a bit more patient and see 😄

[Christian Dräger]

i have the same feeling. i mean in that case the dukat generation helps in terms of not having to write all the types by hand again but we still need to write all that wrapper functions that feels a bit like monkey patching, hard to maintain and error prone.
but i guess since, as you mentioned, the koltin react wrapper has nothing to do with dukat there is no other way. a bit annoying tbh. especially if one would like to use an extensive lib with a big bunch of public functions.
trying out react-leaflet is on my list as well but this would need a huge wrapper and feels like a show stopper in terms of a wide adoption/acceptence of kotlinjs to me 😕

[Joffrey]

I think there is an opportunity for a tool here, separate from Dukat (or maybe that could act as a “plugin” for dukat). It would be aware of react APIs, and could generate extensions based on all react components in the generated types. I wonder if this would be feasible (to which extent the approach could be systematic/automated)

[Christian Dräger]

this sounds like an awesome idea and since there are thousands of libraries that are based on react or extend it, and since I believe that exactly this extensive ecosystem is crucial to the success of react, such a plugin / functionality would make absolute sense in my eyes

[Christian Dräger]

I mean if i wasn’t dependent on react libraries i would probably use another framework to build reactive websites like fritz2, kweb or similar that written in kotlin and thereby have excellent kotlin support for sure. but the ecosystem there is just not sufficient for complex use-cases (at least for my use-cases) if you don’t want to write everything yourself...

[Christian Dräger]

and on the other hand i don't want to start completely from scratch or lets say doing everything different from my current stack.
at least for my current team i can say coming up with the idea to not use react in the frontend and spring-boot in the backend would be much harder for me to convince my team mates to use it as well as migrating our frontend project (backend is written in kotlin already) would be a pain.
But one step after the other. Even for my current playground Project where I try to evaluate if kotlin js could be a daily driver and I have to say I am really opinionated about kotlin and would love to use it for all my frontends the react thing is big hurdle

[Joffrey]

I think it’s the same idea for most of Kotlin’s inception. In the JVM world, the power of Kotlin is Java interop, because if it couldn’t leverage the Java ecosystem it would never have had this much adoption. In the JS world, we need something like Dukat so that we can leverage the JS ecosystem (and TS already paved the way somehow). Now the next natural step follows: if Kotlin react wrappers want to gain traction, we’ll either have to build a whole new ecosystem of component libraries from scratch, or find a way to leverage existing component libraries.

[Christian Dräger]

Totally agree, especially on the java interop