We are running into an issue in JS where abstract ...

# javascript

[Dmitriy Tarasevich]

We are running into an issue in JS where abstract fields within a sealed class are being exported as field_1 even though the typedefs generated have it accessible as field ...

In example

@JSExport
sealed class FooBar() {

    abstract val foo: Int

    data class Bar(override val foo: Int) : FooBar() { }
}

on the JS client, foo is not available but foo_1 is.

Thoughts?

[turansky]

Will it work in this case?

@JsExport
sealed class FooBar() {

    abstract val foo: Int
}

@JsExport
data class Bar(override val foo: Int) : FooBar() { }

[Dmitriy Tarasevich]

hm let me check

[Dmitriy Tarasevich]

It did not.

[Dmitriy Tarasevich]

image-6.png

[Dmitriy Tarasevich]

This is an example of an open val with an override using what you suggested above. Note the _1 and _2

[Edoardo Luppi]

It's only an misunderstanding of how properties are exported.
What you're looking at there is internal fields, but Kotlin properties are exported as getters. See screenshot.

[Edoardo Luppi]

The getter is defined on the FooBar class

//region block: post-declaration
defineProp(protoOf(FooBar), 'foo', function () {
  return this.get_foo_18j5pf_k$();
});

[Edoardo Luppi]

Suggestion to make your life easier: enable ES classes. It will make understanding the compiled JS code much easier.

tasks.withType<Kotlin2JsCompile> {
    compilerOptions {
        useEsClasses = true
    }
}

[turansky]

tasks.withType<Kotlin2JsCompile> {
    compilerOptions {
        target = "es2015" // ES module + ES classes + coroutines on generators
    }
}

Please 🙂

[Edoardo Luppi]

That's handy, yes. The ES classes approach can be useful alongside CommonJS (I use it when deploying to VS Code extensions, which do not support ESM yet)