Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support callbacks through a JS-API builtin

Abierto
  • ¿Algo no está bien?
#743 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
wasm
Área
backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
WebAssembly
Estrellas
1.4k
Forks
132
Merge medio
4 d
PR fusionados (30 d)
12

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/component-model

Todos los issues de WebAssembly/component-model

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.