Closed flimzy closed 5 years ago
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?
As gopherwasm emulates syscall/js, I don't think I'll change this API. Does this make sense?
Yes, that does make sense. Thanks.
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.
The current convention of
gopherwasm/js
is to return and acceptjs.Value
values. This breaks from convention of thegopherjs/js
package to use*js.Object
, and leads to some unnatural/non-idiomatic uses. Example:becomes:
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 thegopherwasm/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?