Skip to content
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

Make the code generator aware of syscall/js and use build tags to write dual output where needed #32

Closed
bradleypeabody opened this issue Apr 5, 2019 · 2 comments

Comments

@bradleypeabody
Copy link
Contributor

bradleypeabody commented Apr 5, 2019

Right now if you import syscall/js in your .vugu file the corresponding .go file will not build server-side. For complex UI's this is an issue. After some discussion at golang/go#31158, this aspect of the syscall/js package is not likely to change. So the Vugu code generator should handle it.

Some basic ideas:

  • The presence of syscall/js could be detected and trigger a path that outputs two files, instead of just comp-name.go it could write comp-name-server.go.
  • The comp-name-server.go would have a !wasm build tag, and all offending types like js.Value could be replaced with interface{} and method bodies for such methods could be implemented with a panic (since server code should never legitimately call it).
  • If the user puts a js.Value member on a struct, it could get replaced with interface{} on the server-side output. Whether this will compile properly depends of course on how the developer is using it.
  • This could handle a lot of simple situations, but there definitely also needs to be a clear path of what the developer should do if this falls short. Using build tags manually should be possible and not terribly difficult.
  • This behavior should be optional, but probably defaulted to on.

Another approach would be to mirror the syscall/js so it gets imported server side as something like import js "github.com/vugu/vugu/js-stub. We'd still need to have a separate file with a build tag, but it could seriously reduce the amount of weirdness required during codegen. I like this idea...

The code generator should probably look for it's "do not edit!" comment before clobbering an existing file, since someone could accidentally get burned if a subtle change add a single js.Value reference now starts outputting another file.

@bradleypeabody
Copy link
Contributor Author

Plan is to make github.com/vugu/vugu/js as a mirror of syscall/js that fully delegates in wasm (ideally with zero overhead), but then in non-wasm it is dumbed down and all of the values are undefined, Truthy() always returns false, Get() always returns undefined, and Call() panics.

Then vugu components can just import js "github.com/vugu/vugu/js" and it does the appropriate thing in each environment. No build tags required in components. Boom

@bradleypeabody
Copy link
Contributor Author

github.com/vugu/vugu/js is now done and being used. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant