Hey, is it expected that I still get mangled names...

# javascript

[bod]

Hey, is it expected that I still get mangled names when using @JsExport ? E.g.:

@JsExport
interface Settings {
  val syncEnabled: Boolean
  val syncItems: Array<SyncItem>
}

@JsExport
data class SettingsImpl(
  override val syncEnabled: Boolean,
  override val syncItems: Array<SyncItem>,
): Settings

results in JS code looking like this:

function SettingsImpl(syncEnabled, syncItems) {
    this.syncEnabled_1 = syncEnabled;
    this.syncItems_1 = syncItems;
  }

[bod]

(Also generally speaking, I'm curious to know the reason for these renames?)

[ephemient]

all names need to be mangled because JS doesn't have overloads (adding a fun syncEnabled() later should not change existing names)

[ephemient]

there is @JsName to give things specific names when exporting

[bod]

but shouldn't @JsExport work here?

[bod]

or maybe I'm missing what it's supposed to do

[ephemient]

// v1
@JsExport
interface Settings {
  val syncEnabled: Boolean
}

// v2
@JsExport
interface Settings {
  val syncEnabled: Boolean
  fun syncEnabled(enable: Boolean)
}

[ephemient]

I guess that's an ABI change in some respects, but if it's not being subclassed from other code, that should be ABI compatible

[bod]

the doc of @JsExport says "Compiled module exposes declarations that are marked with this annotation without name mangling.". What am I missing?

[ephemient]

I take that to mean that the name of Settings itself isn't mangled, and

@JsExport
fun foo()

@JsExport
val bar

shouldn't be either

[bod]

ooh. I think it's already not mangled even without the annotation, but maybe it would be in some cases.

[Edoardo Luppi]

You've probably missed the parts of the JS code that assign the properly named getters to SettingsImpl.

[bod]

yeah not exactly sure... I should try different cases on a very simple project with just one class and compare the JS with/without the annotation. On my huge project it's hard to comprehend 🙂

[Edoardo Luppi]

I can check now for you, but this is a very basic use case and if it doesn't work it's a bug.

[Edoardo Luppi]

Outputted JS

function SettingsImpl(syncEnabled, syncItems) {
  this.n_1 = syncEnabled;
  this.o_1 = syncItems;
}

...

//region block: post-declaration
defineProp(protoOf(SettingsImpl), 'syncEnabled', function () {
  return this.l();
});
defineProp(protoOf(SettingsImpl), 'syncItems', function () {
  return this.m();
});

[bod]

oh so the fields are mangled but not the getters, is that it?

[Edoardo Luppi]

Correct

[bod]

I see! That makes sense. 🙏

My use case is that some of these objects get "jsonified/dejsonified" so the field names are important. So I guess I'll have to use @JsName for that.

[bod]

(I seem to have noticed that the behavior is different for private classes - but I'll have to double check)

[Edoardo Luppi]

@JsName won't change the underlying field. It's always tied to the JS getter.
If you want a plain JS object, you need to work with an external interface.
This is what we need https://youtrack.jetbrains.com/issue/KT-17683

@Artem Kobzar do you think JsField will ever be implemented?

[bod]

oh interesting! But I'm sure I have a case where I have this working (maybe it's private classes then)

[Edoardo Luppi]

IMO you should never take for granted the fields' names. It might work in same cases, and then you introduce an intermediate interface, or a superclass, and it breaks.

[ephemient]

then is it only function names that get mangled then? I still don't see how that can be avoided with overloading

[bod]

I see 🤔 . And when you say I could use an external interface... We usually declare external symbols for stuff that exist in the environment (e.g. types provided by the browser). Is it legal to declare an external for something that doesn't exist? (Or that exists in my code)?

[Edoardo Luppi]

You cannot avoid fields mangling, but getter functions will be properly generated.
In K/JS there is no concept of pure exported fields (in JVM we have @JvmField), every call passes through an associated getter.

[Edoardo Luppi]

Is it legal to declare an external for something that doesn't exist

Absolutely. You just don't have to declare a @JsModule.

The problem in this case is external is only available under JS source sets.
If you want this feature in common code, you need https://youtrack.jetbrains.com/issue/KT-56618

[bod]

all right! Thanks for the pointers 🙏

[Edoardo Luppi]

Another approach I consider viable is augmenting the class in the K/JS backend.
Example:

@JsSerializable
@JsExport
class Example(val one: String, val two: Int)

At compile time the class is augmented with an additional function

@JsSerializable
@JsExport
class Example(val one: String, val two: Int) {
  fun toPlainObject(): ExamplePlain { ... }
}

external interface ExamplePlain {
  val one: String
  val two: Int
}

[Edoardo Luppi]

This is only useful if you need to do stuff on the JS/TS side tho.

[bod]

I see.

[Edoardo Luppi]

Overall, to me it seems that @JsField would solve a bunch of usability issues, included everything we just discussed. That is indeed the better solution.

[bod]

yes I like it!