Request: use *js.Value instead of js.Value

[flimzy]

The current convention of gopherwasm/js is to return and accept js.Value values. This breaks from convention of the gopherjs/js package to use *js.Object, and leads to some unnatural/non-idiomatic uses. Example:

func foo() (*js.Object, error) {
    // ...
    return nil, errors.New(...)
}

becomes:

func foo() (js.Value, error) {
    // ...
    return js.Value{}, errors.New(...
}

This looks ugly, and seems error-prone, as the behavior uninitialized js.Value isn't clearly (if at all) defined to me.

In most of my code, I'm using *js.Value, and converting to/from a pointer when interacting with the gopherwasm/js package, but this is cumbersome.

Is there a reason this choice was made? Or would it make sense to switch to a *js.Value here?

[hajimehoshi]

Is there a reason this choice was made?

It is because syscall/js does that: https://golang.org/pkg/syscall/js/?GOOS=js&GOARCH=wasm

As gopherwasm emulates syscall/js, I don't think I'll change this API. Does this make sense?

[flimzy]

As gopherwasm emulates syscall/js, I don't think I'll change this API. Does this make sense?

Yes, that does make sense. Thanks.

[dmitshur]

as the behavior uninitialized js.Value isn't clearly (if at all) defined to me.

For posterity, that is being tracked in issue golang/go#27592.