go version)?$ go version 1.12
Yes
go env)?go env Output
$ go env
GOARCH="amd64"
GOOS="darwin"
This isn't a bug, but rather a WASM syscall/js feature suggestion. While syscall/js offers extremely helpful functionality for converting Go slices into JS arrays (specifically, func TypedArrayOf()), support for the inverse doesn't exist. This means that, to read a JS array passed into a Go function as a js.Value, one has the following options:
unsafe package to directly access the ref field in js.Value and use the js.Value's length to directly access the bytes starting at ref. Not ideal--requires using reflect to access ref, which is a private field.As a result, passing JS arrays into Go functions in WASM requires extra lift and could benefit from an efficient JS array-to-Go slice conversion.
Check out the example code in
https://github.com/gabbifish/go-wasm-example/blob/master/main.go#L41-L53
Support for converting JS arrays into Go arrays, given that the inverse logic already exists.
^ A hope that this functionality can be offered in Go WASM support in the future :) If there is interest, I'd be happy to work on a PR implementing functionality along these lines.
Yet another approach is to pass the length of the JS array to Go, and create a slice, then pass the slice header pointer to JS and set the wasm linear memory with the JS array at that offset. Takes 2 hops, but does not require reflect.
This is coming up often. I think we should have a standard method in syscall/js before the community comes up with different methods.
@bradfitz @neelance
This is done with https://github.com/golang/go/commit/c468ad04177c422534ad1ed4547295935f84743d. :tada:
Most helpful comment
This is done with https://github.com/golang/go/commit/c468ad04177c422534ad1ed4547295935f84743d. :tada: