Switch from remove callbacks to passing an AbortSignal aborted after removal + accepting a removal promise.

[dead-claudia]

Description

The idea is this: replace onremove and onbeforeremove with:

• An AbortSignal parameter to component creation and views
• A removeReady lifecycle "hook" that's a simple static promise (checking this is as simple as != null and we wouldn't need to call anything, simplifying our side)

Old:

var FancyComponent = {
	onbeforeremove(vnode) {
		vnode.dom.classList.add("exit")
		return new Promise(function(resolve) {
			vnode.dom.addEventListener("animationend", resolve)
		})
	},
	view: () => m(".fancy", "Hello world"),
}

function Async(v) {
	let method = "pending"
	const ctrl = new AbortController()
	let data
	new Promise(resolve => resolve(v.attrs.init(ctrl.signal))).then(
		d => { method = "ready"; data = d; m.redraw() },
		e => { method = "error"; data = e; m.redraw() }
	)
	return {
		view(v) {
			let view = v.attrs[method](
				method === "pending" ? undefined : data
			)
			if (!Array.isArray(view)) view = [view]
			return m.fragment({key: method}, view)
		},
		onremove() {
			if (method === "pending") ctrl.abort()
		},
	}
}

New:

This also includes a simple m.aborted(signal) helper

function FancyComponent(_, signal) {
	let onanimationend, dom
   	return {
		removeReady: new Promise(resolve => onanimationend = resolve),
		view: () => m(".fancy", {
			oncreate(v) { signal.onabort = () => v.dom.classList.add("exit") },
			onanimationend,
		}, "Hello world"),
	}
}

function Async(v, signal) {
	let method = "pending"
	const ctrl = new AbortController()
	let data
	new Promise(resolve => resolve(v.attrs.init(signal))).then(
		d => { method = "ready"; data = d; m.redraw() },
		e => { method = "error"; data = e; m.redraw() }
	)
	return {
		view(v) {
			let view = v.attrs[method](
				method === "pending" ? undefined : data
			)
			if (!Array.isArray(view)) view = [view]
			return m.fragment({key: method}, view)
		},
	}
}

Why

• It's a lot cleaner to use and makes avoiding resource leaks and unnecessarily outstanding requests a lot easier to manage
• Many web APIs ranging from fetch to WHATWG streams to even addEventListener also accept abort signals
• Every major browser aside from IE supports AbortController and AbortSignal - it's below 95%, but about 2% of those users are using ancient versions of modern browsers that most sites don't support anyways. It's also very easily polyfilled (and multiple polyfills exist already for it).
  • Node natively supports it experimentally as of v14.17.0 and fully as of v15.
  • Deno of course has supported it natively the whole time.
  • Some dedicated runtimes like Cloudflare workers also have long supported it.

Possible Implementation

Our remove logic would, instead of invoking remove callbacks, do the following:

• If the vnode has a removeReady promise and this isn't being run from within a .then handler, skip the vnode.
• Schedule a ctrl.abort.bind(ctrl) to run alongside lifecycle hooks
• Visit all the vnode's children using this same recursive algorithm

Creation logic would create the above abort controller, and this would be stored with the vnode.

Open Questions

Do we really want to add a whole vnode field just to support this? Our vnodes are already rather bloated, and the vast majority of our memory usage and GC pressure comes from our vnodes.

I found in Chrome that a single new AbortController() call allocates 188 bytes each (60 for the controller, 128 for the signal). This combined with the slot (4 bytes) comes out to 192 bytes of overhead just for the abort controller alone. That doesn't sit well in light of #2755.

[dead-claudia]

This conflicts with #2690 and as #2282 provides an abort signal anyways, the benefit is too small to outweigh the potential GC performance risk and implementation complexity.