wasm: Port of the library using `sycall/js` #59

yml · 2018-07-05T08:55:57Z

Status: This branch is able to compile and run simple program on GOOS=js GOARCH=wasm

The strategy for this branch follows Dimitry's recomendation.
The advantage is that their is no backward incompatible chnages for gopherjs. The downside is that their is a lot of duplicated code that will need to be kept in sync going forward.
From an API perspective the only incompatible changes is LastModified it now returns an error.

func (d *htmlDocument) LastModified() (time.Time, error) {
...
}

Another unfortunate source of awkwardness is the fact that I had to Named the embded struct to avoid the name conflict with the value in HTMLButtonElement.

I have no prior experience with using this library nor with the gopherjs compiler so everything need to be taken with a grain of salt..

Please let me know if there is any interest in merging this kind of changes in the main repo.

Resolves #57.

dom_wasm.go and event_wasm.go started has a copy of the gopherjs version. I modified them to support `gopherwasm/js`.

Since we have have dedicated files for wasm we can use `syscall/js` directly.

myitcv · 2018-07-05T19:57:38Z

The downside is that their is a lot of duplicated code that will need to be kept in sync going forward.

I think this package needs to shift towards being code generated from the HTML spec, which would mitigate this point, as well as allowing code generation of simple tests too. It would also allow us to remove the slightly awkward usage that comes from having embedded structs.

dominikh · 2018-07-05T20:12:26Z

code generated from the HTML spec

🤣 good luck & have fun to whoever attempts that.

It would also allow us to remove the slightly awkward usage that comes from having embedded structs

How is it awkward? The DOM APIs can be modeled rather well with composition, actually, and the current Go API allows passing "base types" to functions, without having to rely on interfaces and a million getter methods.

dominikh · 2018-07-05T20:16:40Z

Also, what happened to the idea of using github.com/hajimehoshi/gopherwasm for this, to avoid code duplication?

myitcv · 2018-07-05T20:29:50Z

the current Go API allows passing "base types" to functions

My main gripe is actually more a function of the fact that in GopherJS, with *js.Object-special struct types you cannot use struct literals. Even without this restriction, you end up with deeply nested struct literals, when the "equivalent" HTML element is flat. This was my motivation for code generating "exploded" element property types for myitcv.io/react from a very reduced version of the HTML spec to produce things like AProps.

... without having to rely on interfaces and a million getter methods.

In the WASM world, don't we need to do everything with methods in any case? Because we don't have the *js.Object-special types of the GopherJS world which made it possible to use struct fields?

dmitshur · 2018-07-06T03:16:29Z

I think this package needs to shift towards being code generated from the HTML spec

Such a drastic change would need to be considered for v2 or another package. It’s not in scope of this PR/issue.

Also, what happened to the idea of using github.com/hajimehoshi/gopherwasm for this, to avoid code duplication?

The 2nd paragraph of the PR description and the linked comment in the issue describes the rationale.

dominikh · 2018-07-06T11:19:17Z

Well, I'm definitely not a fan of the massive amount of code duplication. That is to say, I'd very much like to avoid it.

yml · 2018-07-06T11:30:15Z

@dominikh Have you seen the initial implementation using gopherwasm/js ?

I see pros an cons to both approaches.

dmitshur

Ok, I've tested the Wasm dom implementation in this PR with github.com/shurcooL/tictactoe, a small/medium-sized project that uses honnef.co/go/js/dom. After making some minor modifications, it was working, which is very promising:

I have 2 change requests for this PR so far, see inline comments.

dmitshur · 2018-07-06T16:24:45Z

dom_wasm.go

+	return els
+}
+
+// TODO (yml): Find out if we really want to modify this signature


We do not want to modify the signature. First, it causes the API to differ between GopherJS and Wasm. Second, it causes *htmlDocument to no longer satisfy the Document interface:

panic: interface conversion: *dom.htmlDocument is not dom.HTMLDocument: missing method LastModified

Third, converting the lastModified Date to string and parsing it back to time.Time is not efficient.

Instead, let's use the same Date -> time.Time conversion process that GopherJS uses (it uses the Date.getTime method), which resolves all those issues:

func (d *htmlDocument) LastModified() time.Time { return time.Unix(0, int64(d.Object.Get("lastModified").Call("getTime").Int()) * 1000000) }

dmitshur · 2018-07-06T16:27:58Z

dom_wasm.go

+// new features are added to the DOM.
+//
+// If you depend on none of the APIs changing unexpectedly, you're
+// advised to vendor this package.


For now, I'd prefer we avoid duplicating the package comment, since we can avoid it. Let's delete it here and in dom.go, and move it to a new file doc.go that just has the package comment and package clause.

Also, please move the import comment to just doc.go file (and remove it elsewhere).

* Moved the comments to a doc.go * Improved to the implementation of LastModified to make the signature compatible

yml · 2018-07-06T19:53:45Z

@shurcooL not sure I did the right thing to approve your changes. I pushed a commit in branch.
Thank you for the quick review and the guidance.

dmitshur

not sure I did the right thing to approve your changes.

Your changes look good so far, thanks for making them!

Just one minor issue I spotted, see inline comment.

dmitshur · 2018-07-06T20:22:51Z

doc.go

+// If you depend on none of the APIs changing unexpectedly, you're
+// advised to vendor this package.
+
+package dom // import "honnef.co/go/js/dom"


The package comment must be immediately preceding the package clause. There can't be a blank line separating them, otherwise it's not parsed as a package comment by godoc. So please remove the blank line on line 113.

Reference: https://golang.org/doc/effective_go.html#commentary.

dmitshur · 2018-07-06T20:26:22Z

dom_wasm.go

-// new features are added to the DOM.
-//
-// If you depend on none of the APIs changing unexpectedly, you're
-// advised to vendor this package.
 package dom // import "honnef.co/go/js/dom"


Let's remove the import comment here as well, so it's only in doc.go file.

yml · 2018-07-06T21:55:38Z

@shurcooL I did all the changes mentioned above.

This time I started to godoc -http=:6060 and I notice that by default if I do not pass GOOS=js GOARCH=wasm the index is empty. When I specify them I see the documentation as expected.

I am wondering if the very exact build target +build js,!wasm and +build js,wasm is not going to cause issue to code completion and the online godoc.org.

dmitshur · 2018-07-08T20:36:20Z

I did all the changes mentioned above.

Perfect, thanks!

I am wondering if the very exact build target +build js,!wasm and +build js,wasm is not going to cause issue to code completion and the online godoc.org.

That's a good catch. godoc.org has support for displaying docs for GopherJS-only packages (see golang/gddo#343), but I think it will treat the current code as an empty linux/amd64 package, displaying no docs other than the package comment.

To fix that, we can just add a // +build js constraint to doc.go to make it constrained to GopherJS and Wasm only. That way, godoc.org will use linux/js (GopherJS) mode for docs.

dmitshur · 2018-07-08T20:39:26Z

(Edit: Moved comment to issue #57.)

myitcv · 2018-07-08T20:51:20Z

@shurcooL

However, I think I've found a potentially show-stopping problem.

This is what I was referring to in #59 (comment):

In the WASM world, don't we need to do everything with methods in any case? Because we don't have the *js.Object-special types of the GopherJS world which made it possible to use struct fields?

dmitshur · 2018-07-08T21:37:04Z

Sorry, I missed that part of your comment.

dmitshur · 2018-07-10T20:39:01Z

Thank you for working on this PR @yml. It has helped us better understand what it looks like to add Wasm support to this package and how viable it was to reuse the existing dom API. We found out that a (significant) breaking API change will be necessary after all, so we'll want to use a different import path.

I'll close this PR since we're not going to proceed with this exact approach, but much of the work done here can carry over into a future PR to implement the updated issue #57. Let's continue to do discussion/planning there.

@yml

This change implements the starting point of a new v2 major version of the dom package. It is now implemented on top of the syscall/js API, which is supported by Go WebAssembly and GopherJS (as of version 1.12-2). The design goal has been to stay as close as possible to v1 API to make the transition easier to make. The only changes that were done were out of neccessity: - All struct fields with `js:"foo"` tags have been replaced with equivalent methods - Underlying() returns js.Value instead of *js.Object - AddEventListener() returns js.Func instead of func(*js.Object) There is a remaining TODO in window.RequestAnimationFrame method to make it so that cancelling the callback via CancelAnimationFrame makes it so the js.Func wrapper's Release method is called. Arranging this is difficult (it requires either having an internal map and sync primitive for tracking js.Func by IDs, or changing the return value of the RequestAnimationFrame method from int to something where the js.Func and its Release method can be accessed easily. The current implementation is functional but may end up using more memory in some situations. It's not blocking for the initial alpha release, so it remains a TODO for now. This implementation was based on work done in by @yml in Pull Request #59. Fixes #57. Co-authored-by: Yann Malet <yann.malet@gmail.com>

@yml

This change implements the starting point of a new v2 major version of the dom package. It is now implemented on top of the syscall/js API, which is supported by Go WebAssembly and GopherJS (as of version 1.12-2). The design goal has been to stay as close as possible to v1 API to make the transition easier to make. The only changes that were done were out of necessity: - All struct fields with `js:"foo"` tags have been replaced with equivalent methods - Underlying() returns js.Value instead of *js.Object - AddEventListener() returns js.Func instead of func(*js.Object) - GetBoundingClientRect() returns *Rect instead of ClientRect Update GetBoundingClientRect to return DOMRect instead of the legacy ClientRect. A breaking API change was needed to make it return a pointer rather than a value, so it was a good opportunity to also update the type at the same time. There is a remaining TODO in window.RequestAnimationFrame method to make it so that canceling the callback via CancelAnimationFrame makes it so the js.Func wrapper's Release method is called. Arranging this is difficult (it requires either having an internal map and sync primitive for tracking js.Func by IDs, or changing the return value of the RequestAnimationFrame method from int to something where the js.Func and its Release method can be accessed easily. The current implementation is functional but may end up using more memory in some situations. It's not blocking for the initial alpha release, so it remains a TODO for now. Document API stability; v2 is currently in alpha and more API changes may be done before it exits alpha state. This implementation was based on work done by @yml in Pull Request #59. Fixes #57. Co-authored-by: Yann Malet <yann.malet@gmail.com> Co-authored-by: Dominik Honnef <dominik@honnef.co> GitHub-Pull-Request: #69

yml added 2 commits July 5, 2018 10:37

wasm: Add support for GOARCH=wasm

0b441a2

dom_wasm.go and event_wasm.go started has a copy of the gopherjs version. I modified them to support `gopherwasm/js`.

wasm: Use syscall/js directly instead of gopherwasm/js

58b5aff

Since we have have dedicated files for wasm we can use `syscall/js` directly.

yml mentioned this pull request Jul 5, 2018

v2: Create with support for both GopherJS and GOOS=js GOARCH=wasm. #57

Closed

dmitshur requested changes Jul 6, 2018

View reviewed changes

wasm: Implemented the feedback from Dmitri Shuralyov

1397d70

* Moved the comments to a doc.go * Improved to the implementation of LastModified to make the signature compatible

dmitshur reviewed Jul 6, 2018

View reviewed changes

wasm: More tweaks

79c6e7e

dmitshur closed this Jul 10, 2018

dmitshur mentioned this pull request May 18, 2019

v2: add dom package #69

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wasm: Port of the library using `sycall/js` #59

wasm: Port of the library using `sycall/js` #59

yml commented Jul 5, 2018 •

edited by dmitshur

Loading

myitcv commented Jul 5, 2018

dominikh commented Jul 5, 2018

dominikh commented Jul 5, 2018

myitcv commented Jul 5, 2018

dmitshur commented Jul 6, 2018

dominikh commented Jul 6, 2018

yml commented Jul 6, 2018 •

edited

Loading

dmitshur left a comment •

edited

Loading

dmitshur Jul 6, 2018 •

edited

Loading

dmitshur Jul 6, 2018 •

edited

Loading

yml commented Jul 6, 2018

dmitshur left a comment

dmitshur Jul 6, 2018 •

edited

Loading

dmitshur Jul 6, 2018

yml commented Jul 6, 2018 •

edited

Loading

dmitshur commented Jul 8, 2018

dmitshur commented Jul 8, 2018 •

edited

Loading

myitcv commented Jul 8, 2018

dmitshur commented Jul 8, 2018

dmitshur commented Jul 10, 2018 •

edited

Loading

wasm: Port of the library using sycall/js #59

wasm: Port of the library using sycall/js #59

Conversation

yml commented Jul 5, 2018 • edited by dmitshur Loading

myitcv commented Jul 5, 2018

dominikh commented Jul 5, 2018

dominikh commented Jul 5, 2018

myitcv commented Jul 5, 2018

dmitshur commented Jul 6, 2018

dominikh commented Jul 6, 2018

yml commented Jul 6, 2018 • edited Loading

dmitshur left a comment • edited Loading

Choose a reason for hiding this comment

dmitshur Jul 6, 2018 • edited Loading

Choose a reason for hiding this comment

dmitshur Jul 6, 2018 • edited Loading

Choose a reason for hiding this comment

yml commented Jul 6, 2018

dmitshur left a comment

Choose a reason for hiding this comment

dmitshur Jul 6, 2018 • edited Loading

Choose a reason for hiding this comment

dmitshur Jul 6, 2018

Choose a reason for hiding this comment

yml commented Jul 6, 2018 • edited Loading

dmitshur commented Jul 8, 2018

dmitshur commented Jul 8, 2018 • edited Loading

myitcv commented Jul 8, 2018

dmitshur commented Jul 8, 2018

dmitshur commented Jul 10, 2018 • edited Loading

wasm: Port of the library using `sycall/js` #59

wasm: Port of the library using `sycall/js` #59

yml commented Jul 5, 2018 •

edited by dmitshur

Loading

yml commented Jul 6, 2018 •

edited

Loading

dmitshur left a comment •

edited

Loading

dmitshur Jul 6, 2018 •

edited

Loading

dmitshur Jul 6, 2018 •

edited

Loading

dmitshur Jul 6, 2018 •

edited

Loading

yml commented Jul 6, 2018 •

edited

Loading

dmitshur commented Jul 8, 2018 •

edited

Loading

dmitshur commented Jul 10, 2018 •

edited

Loading