What do you think about this hack to enable `SomeE...
# javascript
m
What do you think about this hack to enable
SomeExternalInterface.someFun()
? 🤔 This actually compiles and works.
this
will be
null
in
SomeDslClass.Companion.foo
which is okay because it’s not actually used. It allows for a nice DSL with zero overhead for unused Kotlin interface types and companion classes.
Copy code
external interface SomeDslClass {
    @Suppress("NESTED_CLASS_IN_EXTERNAL_INTERFACE")
    companion object
}

fun SomeDslClass.Companion.foo() {
    console.log("it works!")
}

fun main() {
    SomeDslClass.foo()
}
t
Companion
- legal solution, which already used by Kotlin/JS browser classes
m
I gave up on that for now due to another limitation :( https://youtrack.jetbrains.com/issue/KT-43448
t
In IR you can write inline extensions inside external interface It works!
m
It’s not an extension if I write it directly inside the
Companion
.
m
What I need is a non-external companion 🙂
t
Like this?
Copy code
external interface X {
    companion {
        inline fun foo() {
            println("It works!")
        }
    }
}
m
Hmm,
inline
is a good idea. I’d just have to add an additional function to hide away internal/private API which is blocking internal 🤔
I’ll give it a thought. And idea how to nest non-external interfaces inside external interfaces 😄
Oh wait, I also use
val
without getter in some of my Companions. That won’t work.
t
Yes, inline required
Sugar for external -
inline
Feel free to vote :)
m
done 🙂
t
Possibly you also need external “options” 🙂
m
No, I try to avoid interacting with JS as much as possible 😅
t
React props - external options too 🙂 Do you use React?
m
Yes, but I've written a wrapper so that all my props are regular Kotlin classes.