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)

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()))
	}
})

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

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?

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.

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

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))
}

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.

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.

Ensure that cmd/app/main.go uses a prefix in storage to avoid conflict with non-json content

Closes #36

Signed-off-by: Ricardo Seriani [email protected]

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.

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

See https://github.com/golang/go/issues/18152#issuecomment-264322154 and https://github.com/gopherjs/websocket/issues/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.

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."

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.