I’m curious what resolution of [this ticket](<http...

# javascript

[Seth Madison]

I’m curious what resolution of [this ticket](https://youtrack.jetbrains.com/issue/KT-34995) means. Does this meant that the kotlin collections in the stdlib are now exportable to JS? So a JS user could now do:

const kotlinSet = new kotlin.Set(1,2,3)

or does it mean that Kotlin will now use native JS collections internally so that if I do:

val kotlinSet = Set(1.0, 2.0, 3.0)

that would compile to:

const kotlinSet = new Set(1,2,3)

[ephemient]

as far as I can tell, none of the above

[ephemient]

I believe it means that exports like

@JsExport
fun foo(): List<String> = listOf("a", "b", "c")

will be somewhat usable from JS,

const list = foo();
list.get(0) === "a";

[Artem Kobzar]

Yes, @ephemient answer is close to the implementation

[Artem Kobzar]

We merged the ability of using Kotlin collections in exported signatures, and introduce a way to interop with it on JavaScript side

[Artem Kobzar]

So, for the next mentioned code:

@JsExport
fun foo(): List<String> = listOf("a", "b", "c")

From the JS side there will be an ability to interact with at as with the regular JS array.

const result = foo() // KtList<string>
const resultAsArray = result.asReadonlyArrayView() // ReadonlyArray<string>
// So, all the JS array methods are available here
resultAsArray
   .filter(x => x.charCodeAt() < "c".charCodeAt())
   .map(x => String.fromCharCode(x.charCodeAt() + 1))

[Artem Kobzar]

Because it's a view, the collections will not be copied

[Artem Kobzar]

So, changes on the Kotlin side or on JS side will be synchronized

[Artem Kobzar]

You can check the test, that show some of the cases: https://github.com/JetBrains/kotlin/blob/master/js/js.translator/testData/typescript-export/collections/collections__main.ts

[franztesca]

Is there a reason not to return directly the view (the proxy) in the exported code? The intermediate ktlist for example seems useless

[Artem Kobzar]

The only reason is performance and complexity. In the case of automatically converting the list to the view and vice versa, on the Kotlin side, for every exported declaration, we should wrap and unwrap collections (even if they are used in the Kotlin code).

[Artem Kobzar]

Also, I want to mention, that the API is experimental, and we could change it, especially based on the community feedback.

[Edoardo Luppi]

@franztesca so what you're saying is you'd like to get, for example, an `Array`/`ReadonlyArray` right in the exported code/TS types?
But then how would you differentiate it from a Kotlin Array?

[franztesca]

I'd rather sacrifice Array (making it not exportable). The JS Array is actually closer to the list semantics IMHO, and Array is not very Kotlin idiomatic too.
Also, what is the value of differentiating it from an array? Once you're in the JS world, there is not such thing as a list. Having an opaque ktlist that you can just wrap in am array view is not that valuable.

The problem of performance should be acceptable if the API is used by JS users (they would almost always create the view anyway most likely). The fact that this would happen also for code used by Kotlin users is definitely less pleasant, but should be workaroundable somehow. Also, is it common to have a library used both by Kotlin and JS users? 🤔

Great to see the progress happening though K

[Artem Kobzar]

Also, this API can be used from the Kotlin side to put JS Set/Map/Array into some specific JS library

[Edoardo Luppi]

> The fact that this would happen also for code used by Kotlin users is definitely less pleasant
@franztesca what do you mean with this? I don't think you'll ever interact with the proxies on Kotlin's side

> Also, is it common to have a library used both by Kotlin and JS users
I publish for both, although they're for internal use

[Edoardo Luppi]

But in general terms I'd obviously also like to avoid the wrapping, but if there is no clean solution, this seems to be acceptable

[Edoardo Luppi]

Forgot an important point.
We can have multiple implementations of List, Map and Set.
So back to the list > array point, I don't think you can do that straight away.

[Edoardo Luppi]

@Artem Kobzar to confirm, can we export our custom implementations of List and MutableList?
With the interface used in the signature of course.

[Edoardo Luppi]

Looks like the answer is yes, since the asJsArrayView and asJsReadonlyArrayView are default-implemented in the interfaces.

[Artem Kobzar]

Yes, it is possible