Following the instructions as is, here is the error I'm getting in Chrome 71.0.3578.98 (Official Build) (64-bit) with Go version 1.11.4 darwin/amd64

running
wasm_exec.js:45 panic: invalid character 'd' after top-level value
wasm_exec.js:45 
wasm_exec.js:45 goroutine 1 [running]:
wasm_exec.js:45 main.main()
wasm_exec.js:45 	/Users/mattetti/Code/golang/src/github.com/dennwc/dom/cmd/app/main.go:97 +0x4b
wasm_exec.js:67 exit code: 2

It looks like maybe the data in the storage is bad, but I can't easily debug it, nor do I seem to get a lot of clues from the code:

if err := storage.GetItemJSON(stor, key, &s); err != nil {
				panic(err)
			}

Based on the error, it looks like bad JSON but I have no clue how to properly debug :(

Needed to properly iterate over just child elements as desired in #38.

See https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeType for enumerated node types.

This is required for a project I'm working on.

https://developer.mozilla.org/en-US/docs/Web/API/Element/insertAdjacentElement

I followed the instructions in the readme and I got this error(?)

element.go:6:2: build constraints exclude all Go files in /usr/local/Cellar/go/1.11.4/libexec/src/syscall/js

when running go get -u github.com/dennwc/dom

this is my first attempt at playing with wasm so IDK if something in my environment is off. does GOOS or GOARCH need to be set for any of these commands?

We can get and set attributes, but not remove them. Would be useful to add this.

e.g. to remove the 'disabled' attribute on a button.

Event callbacks should call Release() not Close() now. Sent pr #1 to fix.

Looks great!

Trying to do the same thing as this issue => #6 but I think I still miss something ?
In my situation, I have input fields inside a form, can you provide a way to manipulate forms ?
I noticed that looping over the nodeList we got more elements than the actual form ? Any insight on that ?

form := dom.Doc.GetElementById("custom_form")
btn := dom.Doc.GetElementById("btn")
t := document.Call("getElementById", "target")
logger := log.New((*writer)(&t), "", log.LstdFlags)

btn.AddEventListener("click", func(_ dom.Event) {
	nodes := form.ChildNodes()
	for _, element := range nodes {
		logger.Print("ID: " + string(element.Id()) + " Value: " + string(element.JSValue().Get("value").String()))
	}
})

Hello !

Is there any plan to integrate the navigator interface ?
https://developer.mozilla.org/en-US/docs/Web/API/Navigator

Or is there a way to access the same API using wasm ?

How does one get element values with this package?

I tried calling myElement.GetAttribute("value"), but that ended up returning an empty value, rather than the value of my input field.

Is this something that needs additional implementation? Happy to PR something if that's the case.

there is a pure webrtc golang impl here:https://github.com/pions/webrtc

SO i was thinking its maybe possible to do GRPC over Webrtc.
This could then allow p2p style architecture.
it woudl be usable for server to server and server to browser, Or server to desktop client.
So sort of one network transport for everything and GRPC for everything.

what do you think ? I am not sure it will work but its a metetr of trying i suspect.

BTW was very easy to get going and everything works immediatly.
I make it all into a Makefile so no reliance on bash files:

LIB=github.com/dennwc/dom
LIB_FSPATH=${GOPATH}/src/$(LIB)

WASM_FILES="$(GOROOT)/misc/wasm"

GRPC=${LIB_FSPATH}/examples/grpc-over-ws

dep:
	go get -u github.com/dennwc/dom
	go install github.com/dennwc/dom/cmd/wasm-server

open:
	code ${LIB_FSPATH}

##


run:
	cd ${GOPATH}/src/github.com/dennwc/dom && wasm-server

run-ex-grpc:
	cd $(GRPC) && GOOS=js GOARCH=wasm go build -o client.wasm ./client.go
	cd $(GRPC) && cp ${WASM_FILES}/wasm_exec.js ./
	cd $(GRPC) && go run ./server.go

Dear

Please document it so easy to use..

Thanks

Both JavaScript and TypeScript allow access to global objects via dotted notation. At the same time, many libraries wrap their objects, classes and methods to avoid adding them to the global namespace.

Allowing dotted notation in js.Get() would simplify accessing wrapped types and would automatically supplement both js.Class() and js.New(). The following code works:

mdc := js.Get("mdc")
chips := mdc.Get("chips")
chipset := chips.Get("MDCChipSet")
chipsetEl := dom.Doc.CreateElement("div")
chipsetEl.SetAttribute("class", "mdc-chip-set")
chipset.Call("attachTo", chipsetEl)

But this code is much simpler to write and has the added benefit of using the js.Class() caching:

chipset := chips.Class("mdc.chips.MDCChipSet")
chipsetEl := dom.Doc.CreateElement("div")
chipsetEl.SetAttribute("class", "mdc-chip-set")
chipset.Call("attachTo", chipsetEl)

When running wasm-server on this project, if storage already has some items which content isn't JSON, it will conflict.

Web Console Log:

running wasm_exec.js:47:6
panic: invalid character 'v' looking for beginning of value wasm_exec.js:47:6
wasm_exec.js:47:6
goroutine 1 [running]: wasm_exec.js:47:6
main.main() wasm_exec.js:47:6
/tmp/go-wasm/dom/cmd/app/main.go:97 +0x6e

The net.Conn interface doesn't match how WebSockets work as it's not a stream oriented protocol.

See golang/go#18152 (comment) and gopherjs/websocket#29

I think it'd be a good idea to recommend my library instead to avoid duplicate work. It supports compiling to Wasm and provides a more semantically appropriate API (while also providing a net.Conn adapter) or the API in this library should be changed.

I'd like to start using the library but I'm too lazy to read the whole code so it would be nice to see some simple examples in readme

How does the API of this package compare to honnef.co/go/js/dom, a popular DOM package for GopherJS? /cc @dominikh

honnef.co/go/js/dom has issue dominikh/go-js-dom#57 to make API changes to make it possible to add WebAssembly support.

Just wanted to put this on your radar if it's not already, or ask about the design differences so I can understand this package better. Thanks!

In PR #41 I talked about simplifying the signatures of several methods in js.go but rejected that as I thought it would be a breaking change. Since then, I've realized that because the first parameter is the same type as the second variadic parameter, the change is not in fact breaking and simplifies the signature of the end-user API.

I'd suggest that the following three method signatures be changed below:

• From Get(name string, path ...string) to Get(name ...string
• From Class(class string, path ...string) to Class(class ...string)
• From (v Value) Get(name string, path ...string) to (v Value) Get(name ...string)

The change to the Class method slightly simplifies the key generation but otherwise the code is pretty much the same. The main benefit is that, having a single parameter, it makes more sense when a nested class is specified. Consider Class("mdc", "chips", "MDCChipSet") as described in my previous example - with the original signature, the class parameter would contain mdc but the actual class (MDCChipSet) being loaded would be the second element of the path slice. With the revised signature, the elements make sense in the order they're provided.

I do realize this is a completely cosmetic change but wanted to present the idea prior to the library reaching 1.0. If it sounds reasonable, I've got a branch I used to test that this could be done simply - assign this to me and I'll clean up that branch and submit a PR.

The CallbackGroup method OneTimeEvent defines a local boolean fired and it is captured in a Callback closure but the Callback never sets the boolean so it looks superfluous. The intent was probably to set the boolean before the fnc local was called.

Looks like the 'done' variable is created and closed by the Promised method but never waited on. A typo or something subtle going on that I didn't recognize when looking through this code?

I was actually looking for an example of how to marry the idea of the promise's asynchronous calls to onFulfilled and onRejected callbacks with the go-wasm requirement to call Release on the two Callbacks that would have been created, and this wrapper does show that. Each callback is a closure that will release both callbacks once invoked. Nice.

And naively, I was wondering how to slip a call to 'go' in such code to indicate that the callbacks would be done on a separate goroutine but of course it doesn't call go, the javascript Promise will get one of the callbacks invoked on a subsequent trip through the javascript event loop. It was helpful to see this code and have to figure out how to go runtime would handle it without another goroutine being created. A javascript promise is an interesting way to write an asynchronous function without calling go.

It is useful to be able to read the documentation on godoc.

https://godoc.org/github.com/dennwc/dom

Unfortunately the build strings in this project hide the code from the godoc system, which presumably wants to build for linux.

//+build wasm,js

This doesn't seem to be an issue for other projects. Do we really need the build strings?

https://godoc.org/honnef.co/go/js/dom

Hi @dennwc, many thanks for this awesome library. I have a lot of changes i want to push to this but before i start shipping tons of code, i want to ask if there's a way to contact you to discuss some general concepts i would like to see implemented and some changes i want to have in this.

I can also explain here in a ticket but since the ideas i have touch on some basic structures in the lib i would like some input first. I can always push to my fork of course and file a PR for you to see what i am talking about.

Hello,
quick note: I'm go newbie and I've never encountered similar error with other go packages.
I'm trying to use this package using go modules (go.mod). Unfortunately, it seems like only color.go file is visible. Here are my project files:

go.mod:

module goasmf

go 1.12

require github.com/dennwc/dom v0.3.0

main.go:

package goasmf

import (
    "fmt"
    "github.com/dennwc/dom"
)

func main() {
    println("Testing WebAsm!")
    var color dom.Color = "red"
    dom.GetWindow()
}

go build output:

tomek$ go build
# goasmf
./main.go:13:2: undefined: dom.GetWindow

Working without modules and downloading dependency using go get -t github.com/dennwc/dom works fine, though

Problem

The Require(path string) method uses

For instance, the following code:

dom.Require("https://fonts.googleapis.com/icon?family=Material+Icons")

results in the this element in <head>:

<script async="" src="https://fonts.googleapis.com/icon?family=Material+Icons"></script>

A better solution would be to use the Content-Type header returned by the server to decide whether the provided path is a CSS file or a JS file. An added benefit is that the process can fail before it tries to load the added file to the page if the Content-Type doesn't match a supported type.

Workaround

I've temporarily solved this problem by adding a URL fragment to the end of the url as follows:

dom.Require("https://fonts.googleapis.com/icon?family=Material+Icons#.css")

This portion of the URL is not sent to the server but does match the prefix that Require(path string) expects and results in the expected HTML element:

<link type="text/css" rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons#.css">

If compiling with Go 1.13, a compiling error comes up:

github.com/dennwc/dom/js

../../../../go/pkg/mod/github.com/dennwc/[email protected]/js/bytes.go:20:2: undefined: js.TypedArray
../../../../go/pkg/mod/github.com/dennwc/[email protected]/js/bytes.go:30:7: undefined: js.TypedArrayOf

The change log (https://golang.org/doc/go1.13#syscall/js) states that the types have been changed: "TypedArrayOf has been replaced by CopyBytesToGo and CopyBytesToJS for copying bytes between a byte slice and a Uint8Array."

There are now two forks on Github that have on-going maintenance while there's not really any activity here ... should I switch to one of the maintained projects? As you've seen from my previous PRs, I'm not afraid to help with this project but you'd need to be around to at least merge (or reject) the PRs.

go version go1.12beta2 windows/amd64
Google Chrome Version 72.0.3626.81 (Official Build) (64-bit)

missing javascript

Replace syscall/js with gopherwasm/js.

GopherWasm is a wrapper for GopherJS (gopherjs/js) and Wasm (syscall/js). With this, you can make your application work with both GopherJS and Wasm.
GopherWasm's API emulates syscall/js, so please refer syscall/js API document to know how to use API of GopherWasm.

This will allow to compile the programs for wasm and gopherjs without any changes.

After a little struggle I was able to get autocomplete working in VS code by setting some workspace level environment variables. I'm not sure how well known that is. Do you think it is worth adding to the README in this project?

I will gladly open a PR, but if you don't think this is the right place that is understandable.

As detailed here: https://golang.org/doc/go1.12#syscall/js

The changes made to syscall/js have now broken certain parts of the library.

I'd like to know wether or not this is something you are working on.
If not, I'm happy to start looking into it and helping out where able.

Hi! I saw Value{global} being used and global being used for the get & set function. Are they interchangeable?

// Get is a shorthand for Global().Get().
func Get(name string, path ...string) Value {
	return Value{global}.Get(name, path...)
}

// Set is a shorthand for Global().Set().
func Set(name string, v interface{}) {
	global.Set(name, toJS(v))
}