When you use the HTTP handler in development mode (as shown on the Getting Started page), upon page load Vugu will convert your .vugu files into .go and also by default attempt to generate a main_wasm.go if it does not exist. (You can edit main_wasm.go as needed. It is only a template to get your started. Vugu will not overwrite it.)

Like any Go program, it starts with . The build constraint at the top (see Dual Build below) indicates this is the WebAssembly entry point:

To render a page to HTML, you need to have "root" component. This is the top level component that houses everything else. By default this component lives in root.vugu, gets code generated to root.go, which has a Root struct (the component type) and RootData struct (the component's instance data). accepts a ComponentType (Root) and a (nil in this case) and returns an instance that we can use. Like so:

• The second argument is the component instance we created above.
• And the last argument is a map of which component types are available under which names. The function vugu.RegisteredComponentTypes will retreive all of the components that have registered themselves with (which is the case for all components by default). This makes it so you can simply and they will be available automatically. Components defined directly in your main package are also always available by default.

If you need more control over which component types are available during rendering and the names they use, or where your application is output on the page, customizing what you pass to NewJSEnv is the way to do it.

The render loop is where the magic happens. Your components' virtual DOM output (see ComponentType.BuildVDOM) is generated and synchronized with the browser's DOM to give you a matching HTML page. This involves various optimizations including keeping hashes of various pieces of information during rendering so it can cache the result and reduce both compution and the number of calls into the browser to synchronize DOM.

This will call env.Render() immediately the first time and then wait for env.EventWait() to return and render again.

Important Note

EventWait will return false if it detects something wrong with the environment and the program should exit. This should release any resources and be a clean exit from the program when the page goes away.

The discussion above is only about the WebAssembly side of your application.

Using Go's build constraints it is easy to output two different executables from your same package directory. The common case is that you want a client-side build that compiles to WebAssembly (as discussed above), as well as a server-side executable to act as a web server. These each need different main() and likely other functions, but your components and other functionality should be available both in your WebAssembly output and in your server program.