Hi,
The code is Parser is actually a fork that I did some modifications to
(like line number). Can be found at https://github.com/gowebapi/webidlparser
The main flow is currently:
* Parse with webidlparser to get a AST tree.
* Convert into internal types in “github.com/gowebapi/webidl-bind/types”.
* Applying transformation like adding Go packages in “
github.com/gowebapi/webidl-bind/transform”.
* And finally the generation step in “github.com/gowebapi/webidl-bind/gowasm
”.
To use WebIDL to create binding for React.js can be problematic as the
standard as-is doesn’t support for javascript modules. The IDL standard
that WebIDL based on however does. It uses C++ like syntax (foo::bar)
inside “namespace” block. It’s probably not hard to solve.
In the current handwritten library, how is the interaction with JSX solved?
It feels like that normal react.js code is compiled.
Martin
On Mon, Feb 25, 2019 at 7:41 AM Paul Jolly <p...@myitcv.io> wrote:
> I have started to work on DOM binding based on WebIDL and a binding
>> generator. I don't have full WebIDL support yet, but it does process idl
>> from about 80 specifications. See https://gowebapi.github.io for more
>> details.
>>
>
> Hi Martin,
>
> I'd like to second Tyler's suggestion that you start a new thread, very
> exciting!
>
> My question is: to what extent is your WebIDL parser and AST equivalent
> separate from the Go-WASM target code you are generating?
>
> Reason being, I'd like the use the IDL specs to generate Go code for React
> bindings, replacing currently hand-written code. This will likely require
> some sort of tweaks/annotations atop WebIDL for any React vagaries, hence
> I'm wondering to what extent the WebIDL interface is reusable.
>
> Thanks,
>
>
> Paul
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
