A modern programming language that makes developers happier.

kotlinlang

Heyo. Trying to convert a `Uint8Array` into a utf-8 string. Anyone know the best practice way to do this, since a `Uint8Array` isn't back by a `UByteArray` internally (from what I can tell) ?

<https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder|TextEncoder>?

Could use the `TextDecoder` from JS yeah, just not sure how to instantiate it from Kotlin with the js `new` syntax.

`TextEncoder` has to be defined somewhere as `External` no? And it's constructor?

Or you mean just create it something like
```fun TextDecoder(): dynamic = js("new TextDecoder()")```
?

```external class TextEncoder() {
   // required methods
}```

Can't use `TextDecoder` apparently, my `Uint8Array` is too large and `TextDecoder('utf-8').decode(bytes)` fails with `RangeError: Maximum call stack size exceeded in json object.` Seeking other alternatives now.. I might have to chunk this or something.

What is kotlin-js doing when I call `println("bytes: $bytes")` where `bytes` is an `Uint8Array` and it prints out a nice utf-8 encoded string in my console, but when I call `bytes.toString()` it prints out `[...]`? Doesn't embedding something in a string just call its `toString()` internally? Not sure how I could be getting different behavior when I call it manually.

`"bytes: $bytes"` == `"bytes: " + bytes` which Kotlin translates to exactly that in JS. this leads JS to coerce `bytes` to a `String`, which results in the decoding behavior you see

whereas `.toString()` goes through Kotlin's stringification implementation which treats `Array` specially, and `Uint8Array` is an `Array`

a workaround: `(arr.asDynamic().toString)().unsafeCast&lt;String&gt;()` will call JS's `.toString()`, not Kotlin's

K/JSIR appears to compile that to `'' + bytes`, so that would work too, I'm not sure how documented/futureproof that is though

Thanks for the workaround! Got it working :slightly_smiling_face:

FYI - `TextDecoder` <https://github.com/JetBrains/kotlin-wrappers/commit/004bf28113be6023905930f73053dc1bf676fb28|generated> and will be available in next release of wrappers