Reactive engines, probably made well-known in the React.js framework, have rocked the UI world: the clear separation of the state change phase from the full-clean tree rendering phase helped untie some pretty gnarly code bases. One of my personal favorite benefit is on the refactoring side: no more subtle, time-sensitive dependency between components means you can independently modify the visual tree and the time ordering of widgets (including concurrent rendering when relevant).
When we started our journey building SecurityHub (our friendly cyber-security product), we knew we wanted all those benefits for a faster, simpler development experience. But we were also very cognizant of the limitation of React, and even Javascript (quadratic tree diffing algorithm, inability to control object allocations, …) when dealing with a large number of objects – which tends to be a common situation when dealing with any real-world cyber environment!
So we did what every rational person would do: we implemented our own reactive rendering engine. And, because of the tooling we loved around Go, we decided to stick with it in the front-end too. Using WASM.
And, probably to everyone’s surprised (at least mine!), we managed to get a minimal, yet solid prototype in two weeks; further small revisions and tooling improvements later, we have a fast, functional, and enjoyable engine to do front-end development clocking at ~2.5k lines of Go.
The code is available online, but does need a specific, patched runtime – getting 452356 into the standard library is part of my goals for this year!
The rx engine is following (broadly) a three-steps rendering process, building three successful trees:
UI elements under control of the developer are Widgets, implementing a simple interface:
type Widget interface{ Build(Context) *Node }
This interfaces captures the essence of the reactive programming pattern: the rendering phase is a pure function from state to view. The state is updated later by user intents (see the paragraph on Javascript inter-operation for more details), which triggers a new rendering cycle.
A very simple trick means static functions (also called stateless widgets) with the right signature are all valid widgets:
type WidgetFunc func(Context) *Node
func (f WidgetFunc) Build(ctx Context) *Node { return f(ctx) }
As an example, a simple menu widget (in this case to collect an allocation profile) can look like:
func debugmenu() *Node {
return Get(`<div class="z-10 center-float border bg-white flex flex-col absolute flex-auto w-32 h-60">`).AddChildren(
Get(`<button type="button">Allocations Profile</button>`).OnIntent(Click, RequestPProf),
)
}
Many other types instead need to retain state between rendering loops, and are expressed as plain Go structs, and the Build method feel a nice blend of plain old Go code and reactive patterns:
type Ribbon struct {
expandedmenu int
animate bool
}
func (r *Ribbon) Build(ctx rx.Context) *rx.Node {
w := Get(`<div class="absolute top-0 left-0 flex bg-white …">`)
if r.animate {
w.AddClasses("animate-fade-out")
}
}
As a user of the library, that’s pretty much all you need to know to use it.
But keep reading to learn more about the rest of the rendering pipeline, and get a feel for the tradeoffs making the engine tick.