Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support callbacks through a JS-API builtin

Aperta
  • Qualcosa non va?
#743 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
wasm
Ambito
backend-api-design

Direzione di ricerca

Read the callback builtin proposal in this issue alongside Explainer.md#external-visibility-of-types. Work out how the JS-API builtin would represent callback resources and handle their lifecycle, including construction during the start function and ownership cycles. Done means the proposal's open design questions have a resolved specification.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
WebAssembly
Stelle
1.4k
Fork
132
Merge medio
4g
PR unite (30g)
12

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WebAssembly/component-model

Tutte le issue di WebAssembly/component-model

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.