The cookbook: each recipe demonstrates exactly one mechanism in the smallest
correct form, meant to be copied. This is the “copy the smallest correct pattern”
layer beneath the corpus — where the corpus
shows what the system can do, these show how one piece works.
Every recipe runs the same way:
go tool notebook run ./examples/minimal/<name> # interactive, in a browsergo tool notebook check ./examples/minimal/<name> # print the dependency graph
Read them roughly top-to-bottom; each builds on the last. Every recipe links to
its complete source and to the reference page for the mechanism it isolates. Most
are under ~75 lines; a couple (draggable, wrap-existing-package) run longer
because they include a full direct-manipulation rendering or a wrapped API
surface — the line count is noted so you know which is a one-mechanism recipe and
which is a worked example.
a notebook spanning several .go files: only one carries //go:notebook, but cells use types/methods/helpers from the sibling files — it is an ordinary Go package
embed a live notebook as an interactive figure inside another — a text/htmlRender iframe to the inner notebook’s ?embed view; composition without an import (the allowed “notebook as a component” direction, not the forbidden nested graph)
No wiring. Nothing in these files registers a cell, connects an edge, or
imports a reactive framework. The graph is derived from the function signatures
by the Go type checker.
Nothing is required to import. Most recipes import nothing from this project.
htmlcard shows the optionalnb
convenience package (constructors + compile-time interface checks); svgchart
and table show the equivalent zero-import track (a locally-declared Rendered
struct). Pick either — see rendering.