Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Support callbacks through a JS-API builtin

オープン
  • 何か問題がありますか？
#743 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
wasm
領域
backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
WebAssembly
スター
1.4k
フォーク
132
平均マージ
3日 14時間
マージ済み PR（30日）
12

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WebAssembly/component-model のほかの issue

WebAssembly/component-model の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。