Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support callbacks through a JS-API builtin

Đang mở
  • Có gì không ổn?
#743 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
wasm
Lĩnh vực
backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
WebAssembly
Star
1.4k
Fork
132
Merge trung bình
3 ngày 14 giờ
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của WebAssembly/component-model

Tất cả issue của WebAssembly/component-model

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.