Add a built-in component for async view loading

[dead-claudia]

Updates

• Switched to signal as that's what all the various DOM APIs use (and care about) and revised the examples (fixing a bug in the process).
• This is now a sub-bug of Official component/utility library #2284, not Making Mithril more component-driven and less component-oriented #2278.
• Fix to reference Async instead of m.async.
• Update with a new bit using Allow setting the onevent callback per-call for m.redraw #2074.
• Add onAbort callback to init for cancelling requests and similar.
• Fix to rebuild the tree on state change, rather than rebuild

I'm thinking we could add a new component for async view loading, for things like lazy component initialization based on app state, database loading, and reducing the need for route resolvers (which I'm proposing on partially removing in #2278).

Here's my proposed API:

m(Async, {
	// Use this to generate the promise data.
	init: function (signal) {
		const request = requestSomeData()
		signal.onabort = () => request.cancel()
		return request.promise()
	},

	// This returns the view to render while the promise is pending.
	pending: function () {
		// ...
	},

	// This returns the view to render with the resolved promise data, in case
	// of resolution
	ready: function (resolvedData) {
		// ...
	},

	// This returns the view to render with any rejected promise error, in case
	// of rejection
	error: function (rejectedError) {
		// ...
	},
})

If you want to reinitialize it, just wrap it in a keyed fragment and pass a new key.

Implementation-wise, it's pretty simple, and could be implemented trivially in userland.

This, of course, is slightly more complicated, but this has the semantics I'd prefer to see mod sync handling of non-promise return/throw.

Note that this depends on #2074 (comment).

// v2
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()
		},
	}
}

// After #2689
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 v => {
		let view = v.attrs[method](
			method === "pending" ? undefined : data
		)
		if (!Array.isArray(view)) view = [view]
		return m.fragment({
			key: method,
			afterRemove: () => { if (method === "pending") ctrl.abort() }
		}, view)
	}
}

// After #2278 + #2295
function Async(v, o, [method, data] = ["pending", undefined], update) {
	if (o == null) {
		const ctrl = new AbortController()
		new Promise(resolve => resolve(v.attrs.init(ctrl.signal))).then(
			d => update(["ready", d]),
			e => update(["error", e])
		)
		data = () => ctrl.abort()
	}
	return {
		next: [method, data],
		onremove: method === "pending" ? data : undefined,
		view: m(m.keyed, m(m.fragment, {key: method}, v.attrs[method](
			method === "pending" ? undefined : data
		))),
	}
}

[StephanHoyer]

On the first thought: I see this in userland.

[barneycarroll]

I see this in userland.

I agree. Promises can be difficult to deal with declaratively, but ultimately this isn't something that involves any Mithril-specific logic, other than a component to store state. I wrote this component to demonstrate the potential of nested vtree functions - Promiser - which is a simple component that consumes a promise and exposes an explosion of promise state to the consumed view function. Little demo here, line 39 onwards. IMO this is a lot neater - less OO, more obvious state exposure - but I don't think it belongs in core.

[dead-claudia]

It's not really mandatory to have in core, and I addressed the primary use of route resolvers (auth) with a much better-suited abstraction. Would you all be okay with an out-of-core-but-officially-blessed mithril/async?

This is probably the least significant facet of #2278, and I wouldn't have an issue separating this from that.

[StephanHoyer]

not bundled in core but opt in module would be great thought

[dead-claudia]

@StephanHoyer Yeah, I'm starting to agree with that thought. I'll remove it from my list in #2278 and just keep it with my (newly filed) #2284.