-
Notifications
You must be signed in to change notification settings - Fork 9
WASM support #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
WASM support #11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Used "github.com/gopherjs/gopherwasm/js" to try to make it easier to use with both go/wasm and GopherJS. - Only 01-introduction tested, and only with wasm, not GopherJS - You have to use the included server to run with wasm, because "gopherjs serve" does not set the right mime type for .wasm files. The server is fairly stupid because I was lazy; in particular, it only serves wasm files correctly (with the right mime type) if they're in examples/wasm. Still some bugs, still kludgy, but most of examples/01-introduction work. Actually they *all* work, they just cause Vue to throw warnings, since the data functions aren't working correctly. Speaking of which: Vue.js expects to be able to call functions synchronously when creating components (among other places). There is currently *no way* to call a go/wasm function synchronously from JavaScript. So that's going to be broken until synchronous function support comes in. I *did* find a way to write callbacks in such a way so as to capture the "this" value of the callback and pass that on to Go, so I'm happy about that.
- Got Component data funcs closer to doing the right thing. Vue doesn't warn about "data function should return a value" any more, and in the default case of no data func defined, generating an empty data object seems to work. Not tested with real usage yet. - renamed wasm_callback to wasm_call_with_this. Created other JS functions called wasm_return_thing and wasm_new_data_func. - Deleted a bunch of commented-out code, mostly `js:"..."` fields Example 01-introduction works perfectly(?) with no warnings.
So it can be modified from the console.
Fairly big:
- Refined wasm_new_data_func JS trampoline.
- Updated examples/02-lifestyle to work with wasm.
- Tested examples 01 & 02 with GopherJS. Both now work with both, yay!
- Commented out some code hvue.DataFunc(); added a panic, in case
something does call it. It broken.
Fairly minor:
- Changed time.Sleep(time.Hour) back to select{} in
examples/01-introduction/main.go. Before, for some reason, a select{}
at the end of main() would crash with "all goroutines asleep,
deadlock!", but now it doesn't. Probably something about getting
callbacks working correctly? Dunno.
- Cleaned up (removed) some more commented-out code.
- Gave up on computed fields for now. hvue.Computed and hvue.ComputedWithGetSet just panic. - Fixed the mini-server to serve wasm files correctly from anywhere. Updated examples to read wasm_exec.js from vendor. - Converted example 03, 04, and 05. - Added hvue.Watch - Update vendored vue.js
- Lots of work on example 07. Related work on component-related functions, esp. DataFunc & Props. Validators do not work. - Example 04 fixed; it was broken and I didn't even realize. - Example 06 tweaked.
- Whoops: maybe_wasm should be true - Fix typo in server/main
Also: - event.go -- added just enough wrapping around the Event and HTMLElement types to implement example 07. - In example 01, added an example of NewVM setting the VM field of a data object. - Added Log(), which calls console.log().
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updated the core code and the examples so that Go/wasm and GopherJS can both compile and run them. Used github.com/gopherjs/gopherwasm/js as a compatibility layer from go/wasm-style code to GopherJS.
This required api changes: mostly changing from GopherJS's
*js.Objectto go/wasm'sjs.Value(technically, gopherwasm/js'sjs.Value), but there were some more substantive changes, too.Calling a Go function from JavaScript and having it run synchronously and return a value doesn't currently work (golang/go#26045). Vue expects that to work (reasonably enough!). So some hvue functions to wrap that functionality currently just panic. I think
hvue.Computedandhvue.ComputedWithGetSetare the only ones. Some others just do nothing and return (hvue.Validator).Another big difference is that GopherJS has "split" objects, where Go/wasm just has js.Value. That is, in GopherJS, you can say
and then when you set
bar, that automagically translates to settingObject.bar, wherefoo.Objectis the Javascript version of the object. (See https://github.com/gopherjs/gopherjs/wiki/JavaScript-Tips-and-Gotchas for more on that.)Go/wasm doesn't do that. This makes JavaScript object reference quite a bit less magical, which is a good thing, but a little more cumbersome, too (alas). So, you can scatter
.Get("...")and.Set("...", value)everywhere (making typoed field names quite problematic), or you can do like I did and write access functions (where typoed field names are still problematic but much less likely).