Support callbacks through a JS-API builtin #743

Web APIs have extensive use of callbacks (e.g. addEventListener), and the component model doesn't have a way of expressing that.

There's been discussion around adding one, but it's a complicated problem. In the interest of having something working quicker, here is a proposal for adding something just to the JS-API.

Proposal

A callback has:

1. Guest state that it closes over
2. A destructor to clean up that state
3. A function to call providing the closure state and additional parameters

If you squint, that is basically a resource with a single method that is invoked when you call it. Two problems:

1. Exported resources are represented as JS classes (not callable functions).
2. You can't pass a resource you define to one of your imports.

To workaround this, we define a JS-API builtin interface:

(import "wasm:js/callback"
    (instance
        (export "callback" (type $callback (sub resource)))

        (export "[static]callback.my-counter"
            (func (param "my-closure-state" u32) (result (own $callback)))
        )
    )
)

It exports a resource callback. This resource is represented as a JS function that can be passed to other imported APIs.

You build an instance of callback by calling a static method named after a resource type and constructor you export:

(export "my-counter" (type $my-counter (sub resource)))
(export "[constructor]my-counter" (func (param "my-closure-state" u32) (result (own $my-counter))))
(export "[method]my-counter.call" (func ...))

When you call [static]callback.my-counter, the builtin takes the my-closure-state and forwards it around to your exported constructor. It takes the resulting resource type and wraps it into a JS function that it returns back to you. When the JS function is called, it calls the call method on the resource and forwards params/results.

This builtin works around the normal import/export rules to allow you to pass your own exported resource to an import. This can lead to ownership cycles if the callback state is holding a strong reference to something that keeps the callback itself alive.

One question is what happens if you try to construct a callback during the start function? Your components exports aren't available yet. It probably should trap, but that's a big restriction.

Alternatives

Specify your exported resource with a string parameter

Instead of putting your "my-counter" resource name in "[static]callback.my-counter", we could instead have a single imported "[constructor]callback" which takes a string parameter that selects which exported resource to wrap. This is more dynamic and may have worse performance, but lowers the number of imports.

Add a stream based API

Callbacks can be modeled as streams, where every time the callback function is invoked a new entry is written to the stream. The client then reads from the stream asynchronously. This can work for some APIs, but not for APIs where the user needs to synchronously respond to an event (such as to do preventDefault). It also requires async and streams to work.