The resulting math was much easier to reason about, but the Canvas element uses an imperative API, and I missed the nice, declarative view descriptions you get with SVG markup. This is an overview of how I squared that circle to get the best of both worlds: using UI components to abstract Canvas draw calls.

Background

When I last left off with Glyphy, I had gotten as far as completing most of the tedious setup work — parsing OpenType’s binary format to XML via FontTools , deserializing the XML to an in-memory data structure with a custom setup (inspired by Rust’s Serde framework ), parsing the CharString code for each glyph to a bytecode stack, and bootstrapping the front-end using my design system library, Electric — but I hadn’t actually managed to render any glyphs yet. Taking a look at the long list of PostScript operators I would need to implement left me feeling pretty intimidated, and ultimately I got distracted by the next shiny object that entered my field of vision.

But recently I was inspired to pick it back up again. Doing some work in Unreal Engine to implement vector graphics rendering had given me the confidence to take another look at my PostScript interpreter, and selecting the typefaces to use for this blog reminded me what a huge nerd I am for typography — and how disappointing it is that there aren’t many viable options for hobby-level type design software on Windows.

As it turns out, the litany of PostScript operators essentially boils down to the same handful of commands that should be familiar to anyone who’s worked with 2D graphics libraries before:

• MoveTo(x, y) to set the initial coordinates for a new contour.
• LineTo(x, y) to draw a straight line.
• BezierCurveTo(cpx1, cpy1, cpx2, cpy2, x, y) to draw a Bézier curve — with the cp__ parameters representing the “handles” you would manipulate in an application like Adobe Illustrator to adjust the velocity of the curve at a given point.

The rest of the couple dozen or so path construction operators defined by the spec are just different expressions of those same commands, designed to slim down the resulting file size by avoiding repetition or making some operands implicit. After expanding them to the familiar set of MoveTo / LineTo / BezierCurveTo commands, we can trivially apply them to either an HTMLCanvasElement’s 2D rendering context, or an SVGPathElement by stringifying them to its d attribute.

The “problem” with SVG

But there is one minor hiccup with either option, and an additional one when it comes to SVG in particular.

1. OpenType glyphs are defined in the classical Cartesian coordinate space, with the (0,0) origin point at the bottom left (technically, at the font’s baseline in the Y axis), with Y values ascending as you move up, whereas the DOM places the origin at the top-left, with Y values ascending as you move down.
2. For SVG, you also need to wrangle the viewBox attribute , which defines the bounding box of the SVG’s viewport with respect to the coordinates specified on the SVG child elements. If you force the parent SVG element to render at a wider or narrower aspect ratio than that specified by the viewBox, the browser seems to implicitly center the specified viewport within the actual viewport, adding an additional layer of complexity.

I am, at the core of my essence, either an artist with an underdeveloped right-brain or an engineer with an underdeveloped left-brain, depending on how you want to look at it. In a fight, my analytical side would probably win out, but only barely. This unique position enables me to fill an occupational niche that I really love, at the intersection of design and engineering. But when it comes to solving exceptionally challenging problems in either domain…

What I’m trying to say is that I kind of suck at math. I’ve managed to brute-force my way to a pretty decent working intuition for linear algebra (mostly by banging my head against 3D game development problems for the better part of the past five years), so I have no problem building a matrix to transform between glyph-space coordinates and browser-space coordinates and position everything exactly where I want it to appear on the screen. But trying to account for the SVG viewBox situation on top of that was enough to collapse my mental model of the problem like a house of cards.

I managed to hack together this solution, which is workable for rendering a single glyph on its own:

/**
 * @param zoomFactor
 *    Represents how large the bounding box is compared to the glyph height as
 *    measured from `upperBound` to `lowerBound`.
 */
export function getViewBox(
	font: Font,
	glyph: Glyph,
	zoomFactor: number,
	upperBound: (number | keyof FontMetrics) = "ascender",
	lowerBound: (number | keyof FontMetrics) = "descender",
): ViewBox {
	const upper = typeof upperBound === "number"
		? upperBound
		: font[upperBound] ?? font.ascender;
	
	const lower = typeof lowerBound === "number"
		? lowerBound
		: font[lowerBound] ?? font.descender;
	
	const width = glyph.advance ?? 0;
	const remainder = zoomFactor - 1;
	const height = (upper - lower) * zoomFactor;
	const y = ((upper - lower) * remainder) / 2 - lower;
	
	return new ViewBox(0, -y, width, height);
}

But when it comes to building an interactive Bézier curve editor, with a rich, dynamic UI and informative data readouts like the exact glyph-space coordinates of the mouse cursor at any given time, I need to have a firm grasp on the math at play to implement features in a robust way and at a reasonable pace. I wrote the code above less than a month ago, and I would have a seriously hard time explaining, for example, why that y expression produces the desired result. It may as well be an arcane incantation that pleases the eldritch spirits in my GPU.

With the Canvas API, we don’t have to worry about that extra viewport layer. We have the canvas element, which uses the familiar DOM coordinate system (with one confounding variable, the devicePixelRatio, which is trivial to deal with), and then we have our glyph-space coordinates, which we can project into the canvas using a relatively straightforward matrix transformation.

A declarative Canvas API

The one bummer about migrating from SVG to Canvas is the API. Canvas is imperative, in contrast to the declarative nature of XML markup. To “draw” a circle with SVG, you would write something like this:

<svg viewBox="0 0 256 256">
	<circle cx="128" cy="128" r="64" fill="#FFF" />
</svg>

To draw the same circle on a canvas, you would write something like this:

function draw(ctx: CanvasRenderingContext2D) {
	const w = ctx.canvas.width;
	const h = ctx.canvas.height;
	ctx.clearRect(0, 0, w, h);
	
	ctx.beginPath();
	ctx.arc(w/2, h/2, Math.min(w, h)/4, 0, 2*Math.PI);
	
	ctx.fillStyle = "#FFF";
	ctx.fill();
}

You could certainly come up with a more declarative JavaScript API for interacting with the canvas via functions, but I really like the XML family of markup languages for describing UI. The labelled closing tags make it possible to define deeply nested hierarchies of UI elements without losing track of your place in the tree, and attributes are named rather than positional like JS function arguments, so it’s always clear what the value assignments actually represent.

The goal we’re aiming for is something that ends up being very close to SVG for base geometric primitives. In Angular (my daily driver of choice), it looks like this:

<my-canvas>
	<my-circle [cx]="128" [cy]="128" [r]="64" fill="#FFF"></my-circle>
</my-canvas>

The equivalent in React would look something like this:

import Canvas, { Circle } from "../components/canvas";

export const App = () => (
	<Canvas>
		<Circle cx={128} cy={128} r={64} fill="#FFF" />
	</Canvas>
);

export default App;

Implementation

The key to making this work is hierarchical dependency injection. This is a seldom-explored feature in user-land Angular, though the Angular team uses it extensively in the Common and Forms modules and throughout Angular Material. If you’re coming from React, Vue, or SolidJS, you may know this pattern as the “Context API.”

Whatever the host framework, the idea is the same: An instance of some interface is provided at a particular node of the view tree, and then any children of that node who depend on that interface can get a reference to the provided instance by requesting it from the runtime.

We’ll use this pattern to make the canvas host aware of its children who want to render to it. When canvas children are added or removed from the view tree, or when existing canvas children undergo some change that requires them to re-render, they’ll notify the host, which will clear the canvas and invoke a callback for each child, giving it an opportunity to issue draw calls to the canvas.

That’s a pretty abstract explanation and probably more than a little unclear, so we’ll walk through a concrete implementation in Angular (very similar to the one Glyphy is using ), and then we’ll do the same for React. Finally, we’ll look at a clever technique to implement hierarchical dependency injection with plain-old web components, so you can get in on the fun even if you’re not operating in the context of a framework runtime.

Angular

In Angular, we’ll take advantage of the fact that dependency injection is actually a two-way street. That is, not only can a child inject dependencies provided by its parents, but a parent can “query” for dependencies in its children. This is a little odd, but it does make sense for our use case. Since the canvas host is the one driving the render loop, it needs to invoke methods on its child elements rather than the other way around.

Canvas Component

We’ll start by defining the interface through which the host will interact with its children, and an “injection token” which gives the host a generic identifier to query for in lieu of a concrete type.

import { InjectionToken } from "@angular/core";
import { Observable } from "rxjs";

export interface RenderElement {
	readonly changes: Observable<void>;
	onDraw(context: CanvasRenderingContext2D): void;
}

export const RENDER_ELEMENT = new InjectionToken<RenderElement>("RenderElement");

We’ll start the canvas host by setting up the typical boilerplate for an HTML canvas.

import { Component, ElementRef, OnInit, ViewChild } from "@angular/core";

@Component({
	selector: "cv-canvas",
	templateUrl: "./canvas.component.html",
	styleUrls: ["./canvas.component.scss"],
	standalone: true,
})
export class CanvasComponent implements OnInit {
	@ViewChild("canvas", { static: true })
	private _canvasRef!: ElementRef<HTMLCanvasElement>;
	
	get #canvas(): HTMLCanvasElement {
		return this._canvasRef.nativeElement;
	}
	
	#context: CanvasRenderingContext2D | null = null;
	
	ngOnInit(): void {
		const { width, height } = this.#canvas.getBoundingClientRect();
		this.#canvas.width = width * devicePixelRatio;
		this.#canvas.height = height * devicePixelRatio;
		
		this.#context = this.#canvas.getContext("2d");
	}
}

<canvas #canvas class="canvas">
	<ng-content></ng-content>
</canvas>

:host {
	display: block;
	position: relative;
}

.canvas {
	position: absolute;
	inset: 0;
	width: 100%;
	height: 100%;
}

If you’re not overly familiar with Angular: @ViewChild issues a query for some dependency within our component’s template. In this case, we use a string that matches the #canvas template variable to get a reference to the canvas element. (This is conceptually similar to React’s ref attributte.)

static: true indicates that the element isn’t conditional or dynamic in any way — it should always be present when this component is instantiated — which makes it available in the OnInit hook, before our view has fully initialized.

<ng-content> is Angular’s implementation of the <slot> concept — basically analogous to React’s children prop.

Next, we’ll add our DI query, and a #render method to render each of our child RenderElements.

import {
	// ...
	ContentChildren,
	// ...
	QueryList,
} from "@angular/core";

import { RenderElement, RENDER_ELEMENT } from "./canvas.types";

// ...
export class CanvasComponent implements OnInit {
	// ...
	
	@ContentChildren(RENDER_ELEMENT)
	private _elements?: QueryList<RenderElement>;
	
	// ...
	
	#render(): void {
		const ctx = this.#context;
		if (!ctx) return;
		
		ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
		
		if (this._elements)
			for (let element of this._elements)
				element.onDraw(ctx);
	}
}

@ContentChildren is similar to @ViewChild, with two major differences:

• It operates on the nodes passed into our <ng-content> slot, rather than the nodes that we directly declared in our template
• It maintains a dynamic list of results, rather than a single one

Here we’re querying for the RENDER_ELEMENT token we declared earlier, which means that Angular will populate the QueryList with providers of that token.

We want to call our #render method under a few circumstances:

• When the QueryList changes (i.e., because RenderElements were added, removed, or changed their location in the view at runtime)
• When one or more of the RenderElements emits a changes event, indicating that it needs to be re-rendered
• When our canvas element’s size changes, we’ll want to resize its pixel buffer accordingly and redraw everything

In Angular, the primary mechanism for this type of reactive programming today is the third-party RxJS library . To be honest, RxJS is enormously complex, and its role in Angular looks to be soon largely superseded by Angular’s forthcoming Signals implementation , so I’m going to gloss over a lot of the details here.

All you really need to know are that both Angular’s QueryList and our RenderElement interface have a changes property holding an RxJS observable, which is essentially an event emitter. We can subscribe to those observables to be notified when they emit. We’ll use those subscriptions to call our #render method, but we’ll throttle the event streams by window.requestAnimationFrame first so that we only render at most once per frame.

@ContentChildren queries are only available for us to read beginning with the AfterContentInit lifecycle hook, so we’ll implement that and use it to set up our subscriptions. (Annoyingly, we’ll also need to monkey-patch Angular’s QueryList type definition to address a longstanding issue that will trigger an “implicit any” error from TypeScript if we try to use it as-is.)

import {
	AfterContentInit,
	// ...
} from "@angular/core";
import {
	animationFrameScheduler,
	merge,
	Observable,
	shareReplay,
	startWith,
	switchMap,
	throttleTime,
} from "rxjs";

interface IQueryList<T> extends QueryList<T> {
	changes: Observable<IQueryList<T>>;
}

// ...
export class CanvasComponent implements OnInit, AfterContentInit {
	// ...
	
	@ContentChildren(RENDER_ELEMENT)
	private _elements?: IQueryList<RenderElement>;
	
	// ...
	
	ngAfterContentInit(): void {
		const elements$ = this._elements!.changes.pipe(
			startWith(this._elements!),
			shareReplay({ bufferSize: 1, refCount: true }),
		);
		
		const elementChanges$ = elements$.pipe(
			switchMap(queryList => merge(
				...queryList.map(element => element.changes)
			))
		);
		
		merge(elements$, elementChanges$)
			.pipe(
				throttleTime(0, animationFrameScheduler, {
					leading: true,
					trailing: true,
				})
			)
			.subscribe(() => {
				this.#render();
			});
	}
	// ...
}

RxJS is really great at three things:

1. Effortlessly managing complex combinations of event streams from multiple sources like we’re doing here
2. Confusing the hell out of anyone without an encyclopedic knowledge of the operators it provides
3. Making your application leak like a sieve

We’ll address the third point there by making sure none of our subscriptions can outlive our component. To do that, we would have historically used another observable as a notifier for RxJS’s takeUntil operator, which we would emit once in an OnDestroy hook. But Angular recently added its own utility operator, takeUntilDestroyed, that does basically the same thing.

import {
	// ...
	DestroyRef,
	// ...
	inject,
	// ....
} from "@angular/core";
import { takeUntilDestroyed } from "@angular/core/rxjs-interop";

// ...
export class CanvasComponent implements OnInit, AfterContentInit {
	// ...
	#destroyRef = inject(DestroyRef);
	// ...
	ngAfterContentInit(): void {
		const elements$ = this._elements.changes.pipe(
			// ...
			takeUntilDestroyed(this.#destroyRef),
		);
		
		const elementChanges$ = elements$.pipe(
			// ...
			takeUntilDestroyed(this.#destroyRef),
		);
		
		merge(elements$, elementChanges$)
			.pipe(
				// ...
				takeUntilDestroyed(this.#destroyRef),
			)
			.subscribe(() => {
				this.#render();
			});
	}
	// ...
}

Now, the only thing remaining to finish our CanvasComponent is to handle element resizing.

import {
	// ...
	OnDestroy,
	// ....
} from "@angular/core";

// ...
export class CanvasComponent implements OnInit, AfterContentInit, OnDestroy {
	// ...
	#resizeObserver!: ResizeObserver;
	// ...
	ngOnInit(): void {
		// ...
		this.#resizeObserver = new ResizeObserver(([entry]) => {
			const { width, height } = entry.contentRect;
			this.#canvas.width = width * devicePixelRatio;
			this.#canvas.height = height * devicePixelRatio;
			
			this.#render();
		});
		
		this.#resizeObserver.observe(this.#canvas);
	}
	// ...
	ngOnDestroy(): void {
		this.#resizeObserver.disconnect();
	}
	// ...
}

To test that everything is working as expected so far, we can render a blank magenta background in our #render method, and add the component to our app.

// ...
export class CanvasComponent implements OnInit, AfterContentInit, OnDestroy {
	// ...
	#render(): void {
		// ...
		ctx.fillStyle = "#FF00FF";
		// ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
		ctx.fillRect(0, 0, ctx.canvas.width, ctx.canvas.height);
		// ...
	}
}

import "zone.js/dist/zone";
import { Component } from "@angular/core";
import { CommonModule } from "@angular/common";
import { bootstrapApplication } from "@angular/platform-browser";

import { CanvasComponent } from "./canvas/canvas.component";

@Component({
	selector: "cv-app",
	standalone: true,
	imports: [
		CommonModule,
		CanvasComponent,
	],
	templateUrl: "./main.html",
	styleUrls: ["./main.scss"],
})
export class App {}

bootstrapApplication(App);

<cv-canvas></cv-canvas>

:host {
	display: block;
	position: relative;
	width: 100vw;
	height: 100vh;
}

cv-canvas {
	width: 100%;
	height: 100%;
}

If there is now a full-page wall of magenta searing your retinas, we’re good to move on to our first child element!

Circle Component

Let’s keep it simple to start, and implement the circle from our API mockup. Technically, this will be a Directive instead of a Component, because it won’t have any meaningful template or CSS styling. I will, however, give it an element selector — this is atypical for directives, which normally use attribute selectors. But we really don’t care about the host element at all — it’s just a vehicle for the API we’re trying to achieve.

We could hypothetically make these elements useful by using the ARIA API to give screen readers an idea of what our canvas represents — and that is something I actually plan to investigate for Glyphy — but it’s beyond the scope of this toy example.

import {
	Directive,
	EventEmitter,
	Input,
	OnChanges,
	Output,
} from "@angular/core";

import { PaintStyle, RenderElement, RENDER_ELEMENT } from "./canvas.types";

@Directive({
	selector: "cv-circle",
	standalone: true,
	providers: [{
		provide: RENDER_ELEMENT,
		useExisting: CircleDirective,
	}],
})
export class CircleDirective implements RenderElement, OnChanges {
	@Input() cx = 0;
	@Input() cy = 0;
	@Input() r = 0;
	
	@Input() fill: PaintStyle = "black";
	@Input() stroke?: PaintStyle;
	@Input() strokeWidth = 1;
	
	@Output() changes = new EventEmitter<void>();
	
	ngOnChanges(): void {
		this.changes.emit();
	}
	
	onDraw(ctx: CanvasRenderingContext2D): void {
		if (!this.r || !this.fill && (!this.stroke || !this.strokeWidth))
			return;
		
		const cx = this.cx * devicePixelRatio;
		const cy = this.cy * devicePixelRatio;
		const r = this.r * devicePixelRatio;
		
		ctx.beginPath();
		ctx.arc(cx, cy, r, 0, 2*Math.PI);
		
		if (this.fill) {
			ctx.fillStyle = this.fill;
			ctx.fill();
		}
		
		if (this.stroke && this.strokeWidth) {
			ctx.strokeStyle = this.stroke;
			ctx.lineWidth = this.strokeWidth * devicePixelRatio;
			ctx.stroke();
		}
	}
}

A few things worth noting here:

• The providers array in the Directive decorator is how this class hooks into the DI framework so that it can be discovered by the Canvas’s @ContentChildren query.

  The array element can take multiple forms , but this is typically the one you would use in cases like this, where you want to provide some abstract token that represents an interface implementation rather than a concrete @Injectable type.

• We declared changes as an Observable<void> in RenderElement, but we’re defining it as an Angular EventEmitter<void> here. What gives?

  Angular’s EventEmitter class is sneakily an RxJS observable under the hood. Declaring it as an EventEmitter with the @Output decorator means that we could bind a listener to that event in our app template if we really wanted to. We don’t have a use for that, but it’s a free bonus that could theoretically be useful for debugging, so why not?

• If you’re wondering why we’ve been multiplying everything by devicePixelRatio, that’s because the DOM uses a device-independent “pixel” unit virtually everywhere, which doesn’t necessarily correspond to the physical pixels on the user’s display. But the canvas’s width and height properties configure the size of an actual pixel buffer that will be blitted to the canvas surface as a raster bitmap.

  If we didn’t scale our canvas coordinates to account for the difference between the DOM’s px unit and the display’s physical device pixels, we would end up with blurry rendering on displays with high DPIs, or even for users who use the browser-zoom feature to scale up the document.

With that done, we can add a circle to the canvas in our app template and take a look at the results:

// ...
import { CircleDirective } from "./canvas/circle.directive";
// ...
@Component({
	// ...
	imports: [
		// ...
		CircleDirective,
	],
	// ....
})
// ...

<cv-canvas>
	<cv-circle [cx]="128" [cy]="128" [r]="64"></cv-circle>
</cv-canvas>

That puts a static black circle on the screen at a fixed position relative to the top-left corner of the canvas. Which is… neat, I guess? Let’s make it a little more interesting — and prove that our update logic is working the way we expect — by making it interactive.

Adding some interactivity

First, let’s move the circle inputs to our controller, and add a rudimentary hit test to change the cursor style when we’re “hovering” over it.

// ...
export class App {
	cx = 128;
	cy = 128;
	r = 64;
	
	@HostBinding("style.cursor")
	get cursorStyle() {
		if (this.#isHovering) return "grab";
		return null;
	}
	
	#isHovering = false;
	
	onPointerMove(event: PointerEvent): void {
		this.#isHovering = this.#hitTest(event);
	}
	
	#hitTest(event: PointerEvent): boolean {
		const dx = event.clientX - this.cx;
		const dy = event.clientY - this.cy;
		const distSquared = (dx*dx) + (dy*dy);
		
		return distSquared <= (this.r * this.r);
	}
}

<cv-canvas (pointermove)="onPointerMove($event)">
	<cv-circle [cx]="cx" [cy]="cy" [r]="r"></cv-circle>
</cv-canvas>

You should now see the cursor turn into a little grabby hand when you mouse over the circle in the canvas. Now let’s try and move the circle around.

// ...
import { Component, HostBinding, OnDestroy } from "@angular/core";
// ...
import { fromEvent, race, Subject, takeUntil } from "rxjs";
// ...
export class App implements OnDestroy {
	// ...
	@HostBinding("style.cursor")
	get cursorStyle() {
		if (this.#isDragging) return "grabbing";
		if (this.#isHovering) return "grab";
		return null;
	}
	
	#isDragging = false;
	#isHovering = false;
	
	#onDestroy$ = new Subject<void>();
	
	ngOnDestroy(): void {
		this.#onDestroy$.next();
		this.#onDestroy$.complete();
	}
	
	onPointerDown(event: PointerEvent): void {
		if (!this.#hitTest(event))
			return;
		
		this.#isDragging = true;
		
		fromEvent<PointerEvent>(event.target!, "pointermove")
			.pipe(
				takeUntil(race(
					fromEvent(window, "pointerup"),
					fromEvent(window, "pointerleave"),
					this.#onDestroy$,
				)),
			)
			.subscribe({
				next: event => {
					this.cx += event.movementX;
					this.cy += event.movementY;
				},
				complete: () => {
					this.#isDragging = false;
				},
			});
	}
	// ...
}

<cv-canvas
	(pointerdown)="onPointerDown($event)"
	(pointermove)="onPointerMove($event)"
>
	<cv-circle [cx]="cx" [cy]="cy" [r]="r"></cv-circle>
</cv-canvas>

Now you should be able to grab onto the circle and drag it around the viewport! For one last flourish, let’s make the scroll wheel resize the circle.

// ...
export class App implements OnDestroy {
	// ...
	onWheel(event: WheelEvent): void {
		let factor = -(event.deltaY / devicePixelRatio / 85);
		if (factor < 0) factor = 1 / Math.abs(factor);
		
		this.r = Math.max(1, Math.min(1000, this.r * factor));
	}
	// ...
}

<cv-canvas
	(pointerdown)="onPointerDown($event)"
	(pointermove)="onPointerMove($event)"
	(wheel)="onWheel($event)"
>
	<cv-circle [cx]="cx" [cy]="cy" [r]="r"></cv-circle>
</cv-canvas>

React

For the React implementation, I’m going to assume you’re already pretty familiar with the framework (because, for better or worse, most front-end developers are).

The trickiest part here will be translating our setup to React’s Context API. As mentioned at the start of the Angular implementation, the parent component that hosts the canvas element needs to be the driver of the render loop — it should invoke some callback provided by its children whenever a re-render is called for. But we can’t query our children for a particular interface implementation like we did in Angular.

Canvas Context

I’m admittedly much less familiar with React than I am with Angular, so I would welcome any suggestions for how to do this more idiomatically, but the solution I arrived at was to provide a class instance as a context object to all children of the canvas element. When children who are interested in rendering to the canvas are added to the view tree, they’ll register their onDraw callback with the context object. We’ll then invoke each of those callbacks whenever React renders our Canvas component. Here’s what that looks like:

import { createContext } from "react";

export interface ICanvasContext {
	onDraw(callback: (context: CanvasRenderingContext2D) => void): void;
}

export const CanvasContext = createContext<ICanvasContext | null>(null);

import {
	forwardRef,
	type HTMLProps,
	type ReactNode,
	type RefObject,
	useMemo,
	useRef,
} from "react";

import { CanvasContext, type ICanvasContext } from "./CanvasContext";

export interface Props extends HTMLProps<HTMLDivElement> {
	cursor?: string;
	children?: ReactNode | ReactNode[];
}

export const Canvas = forwardRef<HTMLDivElement, Props>(
	({ cursor, children, ...props }, ref) => {
		const canvasRef = useRef<HTMLCanvasElement>(null);
		const context = useMemo(() => new CanvasContextImpl(canvasRef), [canvasRef]);
		
		context._reset();
		
		requestAnimationFrame(() => {
			context._render();
		});
		
		return (
			<div {...props}
				ref={ref}
				style={{
					width: "100vw",
					height: "100vh",
					position: "relative",
					cursor,
					...(props.style ?? {})
				}}
			>
				<canvas ref={canvasRef}
					style={{
						position: "absolute",
						inset: 0,
						width: "100%",
						height: "100%",
					}}
				>
					<CanvasContext.Provider value={context}>
						{children}
					</CanvasContext.Provider>
				</canvas>
			</div>
		);
	}
);

export default Canvas;

interface Fn<Args extends any[], R> {
	(...args: Args): R;
}

class CanvasContextImpl implements ICanvasContext {
	#elements: (Fn<[CanvasRenderingContext2D], void> | null)[] = [];
	#ptr = 0;
	
	#canvasRef: RefObject<HTMLCanvasElement>;
	#context: CanvasRenderingContext2D | null = null;
	
	get #canvas() {
		return this.#canvasRef.current;
	}
	
	constructor (canvasRef: RefObject<HTMLCanvasElement>) {
		this.#canvasRef = canvasRef;
		if (this.#canvas) {
			this.#initializeContext();
		}
	}
	
	onDraw(callback: Fn<[CanvasRenderingContext2D], void>): void {
		if (this.#elements.length <= this.#ptr) {
			this.#elements.push(callback);
		} else {
			this.#elements[this.#ptr] = callback;
		}
		
		this.#ptr++;
	}
	
	_reset(): void {
		for (let i = 0; i < this.#elements.length; ++i)
			this.#elements[i] = null;
		
		this.#ptr = 0;
	}
	
	_render(): void {
		if (!this.#canvas) return;
		if (!this.#context) {
			this.#initializeContext();
		}
		if (!this.#context) return;
		
		const ctx = this.#context;
		ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
		
		for (let onDraw of this.#elements) {
			if (!onDraw) break;
			onDraw(ctx);
		}
	}
	
	#initializeContext(): void {
		if (!this.#canvas) return;
		
		const { width, height } = this.#canvas.getBoundingClientRect();
		this.#canvas.width = width * devicePixelRatio;
		this.#canvas.height = height * devicePixelRatio;
		
		this.#context = this.#canvas.getContext("2d");
	}
}

There are a few interesting optimizations we need to do here that we didn’t really have to think about in the Angular implementation:

• Virtually everything in React is transient by default, but it’s not trivially cheap to initialize a canvas element’s rendering context or to set its width and height properties, so we want to avoid needing to do that every time our component renders. To that end, we instantiate our CanvasContextImpl class with useMemo (dependent only on the canvasRef) to keep it reference-stable between React renders.

• If we can avoid it, we also don’t really want to thrash the garbage collector by reallocating the array of child callbacks every frame, but each of our children will invoke the context object’s onDraw method anew every time our canvas re-renders. To mitigate the performance impact, we’ve added a pseudo-private _reset method for our host component to invoke, which will “reset” the array without actually resizing or disposing it. We keep a separate “pointer” into the array just past its last populated index, and as long as the array still has some unused capacity remaining, we insert new callbacks at that index instead of pushing them.

  To be honest, this is the type of micro-optimization that’s likely out of place in a JavaScript app — the browser’s JS runtime may already be doing that sort of optimization for us, and we may even be preventing it from doing more effective optimizations by making the array heterogeneous to accomodate the null entries. Profiling would be a good idea here, but since this is a toy example for a blog post and not actual production code, I haven’t gone to the trouble. If you decide to look into it, do let me know what you find!

We’ll round out the Canvas implementation by handling resizes, much like we did in Angular:

import {
	// ...
	useEffect,
	// ...
} from "react";
// ...
	({ cursor, children, ...props }, ref) => {
		// ...
		const context = useMemo(() => new CanvasContextImpl(canvasRef), [canvasRef]);
		
		const onResize = useCallback(([entry]: ResizeObserverEntry[]) => {
			const { width, height } = entry.contentRect;
			context._resize(width, height);
		}, [context]);
		
		const resizeObserver = useMemo(() => new ResizeObserver(onResize), [onResize]);
		
		useEffect(() => {
			if (canvasRef.current)
				resizeObserver.observe(canvasRef.current);
			
			return () => {
				if (canvasRef.current)
					resizeObserver.unobserve(canvasRef.current);
			}
		}, [canvasRef, resizeObserver]);
		// ...
	}
// ...
class CanvasContextImpl implements ICanvasContext {
	// ...
	_resize(width: number, height: number): void {
		this.#canvas!.width = width * devicePixelRatio;
		this.#canvas!.height = height * devicePixelRatio;
		this._render();
	}
	// ...
}

Porting from Angular

The remainder of the React implementation is a pretty straightforward port of the Angular code, so I won’t spill too much ink over it. Maybe the one notable quirk is that our child Circle needs to return an empty React.Fragment to avoid TypeScript complaining that it doesn’t qualify as a component (though React itself didn’t seem to mind the omission).

import { useContext } from "react";

import { CanvasContext } from "./CanvasContext";

export interface Props {
	cx: number;
	cy: number;
	r: number;
}

export default ({ cx, cy, r }: Props) => {
	const canvas = useContext(CanvasContext);
	canvas?.onDraw(ctx => {
		ctx.beginPath();
		ctx.arc(
			cx * devicePixelRatio,
			cy * devicePixelRatio,
			r * devicePixelRatio,
			0,
			2 * Math.PI,
		);
		
		ctx.fillStyle = "black";
		ctx.fill();
	});
	
	return <></>;
}

export { default, type Props as CanvasProps } from "./Canvas";
export { default as Circle, type Props as CircleProps } from "./Circle";

import { useEffect, useState } from "react";

import Canvas, { Circle } from "./Canvas";
import "./style.css";

export default function App() {
	const [cx, setCx] = useState(128);
	const [cy, setCy] = useState(128);
	const [r, setR] = useState(64);
	
	const [isDragging, setDragging] = useState(false);
	const [isHovering, setHovering] = useState(false);
	const [cursor, setCursor] = useState<string|undefined>();
	
	useEffect(() => {
		if (isDragging) {
			setCursor("grabbing");
		} else if (isHovering) {
			setCursor("grab");
		} else {
			setCursor(undefined);
		}
	}, [isHovering, isDragging]);
	
	function beginDrag(_: React.PointerEvent): void {
		if (isHovering) {
			setDragging(true);
		}
	}
	
	function endDrag(): void {
		setDragging(false);
	}
	
	function onPointerMove(event: React.PointerEvent): void {
		setHovering(hitTest(event));
		if (isDragging) {
			setCx(cx + event.movementX);
			setCy(cy + event.movementY);
		}
	}
	
	function onWheel(event: React.WheelEvent): void {
		let factor = -(event.deltaY / devicePixelRatio / 85);
		if (factor < 0) factor = 1 / Math.abs(factor);
		
		adjustRadius(factor);
	}
	
	function hitTest(event: React.PointerEvent): boolean {
		const { clientX, clientY } = event;
		const dx = clientX - cx;
		const dy = clientY - cy;
		const d2 = (dx*dx) + (dy*dy);
		
		return (d2 <= (r*r));
	}
	
	function adjustRadius(factor: number, min = 1, max = 1000): void {
		setR(Math.max(min, Math.min(max, r * factor)));
	}
	
	return (
		<Canvas
			cursor={cursor}
			onPointerDown={beginDrag}
			onPointerUp={endDrag}
			onPointerMove={onPointerMove}
			onWheel={onWheel}
		>
			<Circle cx={cx} cy={cy} r={r} />
		</Canvas>
	);
}

A pesky issue with React.StrictMode

One mildly infuriating problem, which I don’t have a good answer to at the moment, is that React’s StrictMode forces every component to render twice in dev builds as a debugging aide. Angular does something similar by running an extra change detection cycle in development, but the fact that we’re relying on React’s component renders to collect draw calls from our children means that we’ll end up with two onDraw callbacks for every single RenderElement added to our canvas. Memoization and useCallback are no help either — onDraw gets invoked with two equivalent but referentially-unique callbacks no matter what we try to do about it in user-land.

This sounds like just a performance issue at first, but canvas draw calls are alpha-blended, so it actually leads to a visibly different result in development vs production, which is really not ideal — you don’t want to merge and deploy a PR only to find that it looks significantly different than you expected out in the real world.

I ultimately resorted to removing the StrictMode wrapper in my test project, but if you were going to try something like this in real-world production code, you would definitely want to come up with a more robust solution. Adding an if branch to skip every other callback when not in production is hacky and inelegant, but would likely do the trick.

Bonus: Web Components

One of the biggest hassles of working on the web today is how fragmented the entire ecosystem is. Multiple bundlers and build systems, multiple TypeScript compilers, multiple mechanisms for module import/export/resolution, and of course a zillion or so mutually incompatible front-end frameworks. I’ve walked through solutions for the two most popular frameworks as of writing, but what if you’re working in Vue, or SolidJS, or even just vanilla JS/HTML/CSS?

The web components spec is widely implemented across modern browsers, which gives us a way to build UI features that are framework-agnostic. The only hiccup is that the crux of our solution is designed around hierarchical dependency injection. Dependency injection as part of the web components spec doesn’t even really make sense to talk about: the whole point of dependency injection is to enable dependency inversion — depending on abstract interfaces rather than concrete types — which is a concept that’s inseparable from static type systems.

Fortunately, the web components API gives us all of the tools we need to bootstrap a really straightforward DI implementation! I wish I could take credit for this idea: I yoinked it from Justin Fagnani , a Google engineer working on Lit . I recommend checking out the talk that inspired this solution on YouTube.

Dependency injection without a framework

The seed of the idea is that custom elements (web components) can dispatch custom events. CustomEvent is a generic derivative of Event, with a detail property that we can populate with arbitrary data. An implementation of the classic bottom-up DI model (which Justin covers in his talk) goes something like this:

• A custom element with an abstract dependency emits a custom event, populated with some identifier representing the interface it depends on.
• A custom element which provides a dependency is listening for that event type. If it provides a match for the requested identifier, it mutates the custom event data to populate it with the provided instance, and then stops the event from propagating any further up the tree.
• Since DOM events bubble synchronously, the dependent can retrieve the provided instance from the event immediately after dispatching it.

From there, it’s a short walk to get to the top-down “query” model we used in our Angular implementation:

• In addition to listening for events from below, the dependency provider emits its own event, populated with both the interface ID and the concrete instance.
• To query for dependencies provided by descendants, the ancestor element listens for the provider event and retrieves any instances they’re interested in.

I’ll use Lit for the WC implementation of our drag-the-circle demo, but you could follow the steps above with (or without) any web components framework, as long as you have some mechanism for managing (and preferably batching) reactive updates. You’ll notice some striking similarities between this and the Angular implementation, which is no surprise since Angular, Lit, and the web components spec itself all have Googley genes in their DNA.

Porting from Angular

First, we’ll knock out the stuff that should be pretty familiar at this point:

export interface RenderElement {
	onDraw(context: CanvasRenderingContext2D): void;
}

export type PaintStyle
	= string
	| CanvasGradient
	| CanvasPattern
	;

import { LitElement, PropertyValues, css, html } from "lit";
import { customElement, state } from "lit/decorators.js";
import { Ref, createRef, ref } from "lit/directives/ref.js";

import { RenderElement } from "./canvas.types";

@customElement("cv-canvas")
export class CanvasElement extends LitElement {
	static override styles = css`
		:host {
			display: block;
			position: relative;
		}
		
		.canvas {
			position: absolute;
			inset: 0;
			width: 100%;
			height: 100%;
		}
	`;
	
	override render() {
		queueMicrotask(() => this.#renderCanvas());
		
		return html`
			<canvas class="canvas" ${ref(this.#canvasRef)}>
				<slot></slot>
			</canvas>
		`;
	}
	
	@state()
	private _elements: RenderElement[] = [];
	
	#canvasRef: Ref<HTMLCanvasElement> = createRef();
	get #canvas(): HTMLCanvasElement | undefined {
		return this.#canvasRef.value;
	}
	
	#context: CanvasRenderingContext2D | null = null;
	#resizeObserver: ResizeObserver;
	
	constructor () {
		super();
		
		this.#resizeObserver = new ResizeObserver(([entry]) => {
			const { width, height } = entry.contentRect;
			this.#canvas!.width = width * devicePixelRatio;
			this.#canvas!.height = height * devicePixelRatio;
			
			this.#renderCanvas();
		})
	}
	
	override firstUpdated(changes: PropertyValues): void {
		super.firstUpdated(changes);
		
		if (!this.#canvas)
			throw new Error("HTMLCanvasElement not found!");
		
		const { width, height } = this.#canvas.getBoundingClientRect();
		this.#canvas.width = width * devicePixelRatio;
		this.#canvas.height = height * devicePixelRatio;
		
		this.#context = this.#canvas.getContext("2d");
		this.#resizeObserver.observe(this.#canvas);
	}
	
	override disconnectedCallback(): void {
		super.disconnectedCallback();
		
		this.#resizeObserver.disconnect();
	}
	
	#renderCanvas(): void {
		const ctx = this.#context;
		if (!ctx) return;
		
		ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
		
		for (let element of this._elements)
			element.onDraw(ctx);
	}
}

import { LitElement, PropertyValues, html } from "lit";
import { customElement, property } from "lit/decorators.js";

import { PaintStyle, RenderElement } from "./canvas.types";

@customElement("cv-circle")
export class CircleElement extends LitElement implements RenderElement {
	@property() cx = 0;
	@property() cy = 0;
	@property() r = 0;
	
	@property() fill: PaintStyle = "black";
	@property() stroke?: PaintStyle;
	@property() strokeWidth = 1;
	
	onDraw(ctx: CanvasRenderingContext2D): void {
		if (!this.r || !this.fill && (!this.stroke || !this.strokeWidth))
			return;
		
		const cx = this.cx * devicePixelRatio;
		const cy = this.cy * devicePixelRatio;
		const r = this.r * devicePixelRatio;
		
		ctx.beginPath();
		ctx.arc(cx, cy, r, 0, 2*Math.PI);
		
		if (this.fill) {
			ctx.fillStyle = this.fill;
			ctx.fill();
		}
		
		if (this.stroke && this.strokeWidth) {
			ctx.strokeStyle = this.stroke;
			ctx.lineWidth = this.strokeWidth * devicePixelRatio;
			ctx.stroke();
		}
	}
}

import { LitElement, css, html } from "lit"
import { customElement, state } from "lit/decorators.js"

import "./canvas/canvas.element";
import "./canvas/circle.element";

@customElement("cv-app")
export class AppRoot extends LitElement {
	static override styles = css`
		:host {
			display: block;
			position: relative;
			width: 100vw;
			height: 100vh;
		}
		:host(.hovering) {
			cursor: grab;
		}
		:host(.dragging) {
			cursor: grabbing;
		}
		
		cv-canvas {
			width: 100%;
			height: 100%;
		}
	`;
	
	override render = () => html`
		<cv-canvas
			@pointermove=${this.#onPointerMove}
			@pointerdown=${this.#onPointerDown}
			@pointerup=${this.#onPointerUp}
			@wheel=${this.#onWheel}
		>
			<cv-circle
				.cx=${this._cx}
				.cy=${this._cy}
				.r=${this._r}
			></cv-circle>
		</cv-canvas>
	`;
	
	@state() private _cx = 128;
	@state() private _cy = 128;
	@state() private _r = 64;
	
	#_isHovering = false;
	get #isHovering() { return this.#_isHovering; }
	set #isHovering(value) {
		this.classList.toggle("hovering", value);
		this.#_isHovering = value;
	}
	
	#_isDragging = false;
	get #isDragging() { return this.#_isDragging; }
	set #isDragging(value) {
		this.classList.toggle("dragging", value);
		this.#_isDragging = value;
	}
	
	#onPointerMove = (event: PointerEvent) => {
		this.#isHovering = this.#hitTest(event);
		
		if (this.#isDragging) {
			this._cx += event.movementX;
			this._cy += event.movementY;
		}
	}
	
	#onPointerDown = () => {
		this.#isDragging = this.#isHovering;
	}
	
	#onPointerUp = () => {
		this.#isDragging = false;
	}
	
	#onWheel = (event: WheelEvent) => {
		let factor = -(event.deltaY / devicePixelRatio / 85);
		if (factor < 0) factor = 1 / Math.abs(factor);
		
		this._r = Math.max(1, Math.min(1000, this._r * factor));
	}
	
	#hitTest(event: PointerEvent): boolean {
		const dx = event.clientX - this._cx;
		const dy = event.clientY - this._cy;
		const d2 = (dx*dx) + (dy*dy);
		
		return d2 <= (this._r * this._r);
	}
}