Support ComputedSource on the browser platform

[sargunv]

ComputedSource throws UnsupportedOperationException on the browser. MapLibre GL JS parses tiles in a web worker, so the per-tile getFeatures callback cannot run on the main thread where the app supplies it.

The path to take is addProtocol behind a vector source, with the handler encoding each computed tile as MVT. That needs an MVT encoder in Kotlin, which belongs in maplibre/spatial-k rather than here.

The alternative is addSourceType paired with a worker source registered through importScriptInWorkers and self.registerWorkerSource, which MapLibre documents as experimental, and which would put the callback in a worker, not practical for Kotlin JS/Wasm today.

Until then, GeoJsonSource with setData covers the common case.

[sargunv]

@cursoragent explore the implications of "callback in a worker" for Kotlin JS and Wasm (we have a draft with the Wasm port). Are there any worker related limitations in today's Kotlin? Cite sources, especially KEEPs and YouTrack tickets.

[cursor]

You cannot put a live Kotlin GeometryTileProvider (the old ComputedSource callback) into MapLibre’s workers. Kotlin still has no first-class worker/callback-shipping story, and Kotlin/Wasm makes that path worse, not better. The viable browser model is the one already used for CustomVectorSource: run the Kotlin callback on the main thread via addProtocol, then let MapLibre parse the tile in its own workers.

What “callback in a worker” actually means

MapLibre’s experimental path is importScriptInWorkers plus self.registerWorkerSource. That does not accept a function from the page. It broadcasts a script URL into MapLibre’s existing worker pool, and each worker loads it with classic importScripts():

this.actor.registerMessageHandler(MessageType.importScript, async (_mapId, params: string) => {
  this.self.importScripts(params);
});

importScripts only works in classic workers. It throws in module workers (MDN). The worker then constructs a WorkerSource and calls loadTile there.

The app callback in this library is a suspend fun interface:

public fun interface GeometryTileProvider {
  public suspend fun loadTile(tile: TileCoordinate): FeatureCollection<*, *>
}

That object typically captures Compose state, Ktor clients, and a coroutine scope on the main Kotlin runtime. Getting it into MapLibre’s isolate is the whole problem.

The hard limit: you cannot ship a Kotlin lambda

This is a platform rule, not a missing helper.

Structured clone, which postMessage uses, cannot clone functions. Doing so throws DataCloneError (MDN).

JetBrains wrote the same thing into the still-unshipped worker KEEP (notes/web-workers.md, KEEP-241, status Under consideration):

The worker thread does not have access to the main thread's address space. … worker threads are more like processes … only objects … which can be copied using [structured cloning] can be sent … The most notable objects, which are not supported, are functions, the prototype chain, and DOM nodes.

unlike the thread function, our yet theoretical worker function cannot accept any lambda. The lambda is not copyable, and … should be known at compile-time so that the compiler can put it in a separate JavaScript file.

The proposed worker { } intrinsic only accepted an inline block, not a stored lambda. Passing GeometryTileProvider would be a compile error under that design.

The same KEEP is explicit about coroutines: you cannot transfer a Continuation, because it holds a function. GeometryTileProvider.loadTile is suspend, so that restriction applies directly.

KEEP notes/0002-code-coloring.md (KEEP-240) repeats it: workers must be known at compile time, the prototype only accepted inline-only lambdas, DOM is banned, and captured types must be serializable. It also says Compose and workers should not compose:

while it makes sense to compose web-workers and coroutines, there is no sense in composing web-workers and JetPack Compose

None of that compiler support shipped.

Kotlin/JS today: no worker target, no callback transfer

Ticket	State	What it says
KT-45455 KJS: Worker target support	Obsolete	Asked for @JsWorker / multiple worker compilations in one Gradle project. Closed obsolete; never shipped.
KT-71392 Non-Node runtime targeting	Backlog	KGP still only has browser() and nodejs(). Workers, Deno, Cloudflare, etc. are not a target.
KT-47038 Split JS target into JsBrowser and JsNode	To be discussed	Even browser vs Node is not split, so there is no worker-safe API surface.
KT-71391	Duplicate	es2015 used eval for coroutines; that breaks restricted isolates.

kotlinx.coroutines on JS/Wasm is an event-loop scheduler, not a thread pool. Dispatchers.Default is the same isolate (kotlinx.coroutines#4688: use Default in a worker because window.asCoroutineDispatcher does not exist there). kotlinx.coroutines#4561 still points at KT-45455 as the reason a KMP library cannot put non-trivial work in a worker.

What you can do on JS is the manual two-program model: a second compilation, a second bundle, new Worker("worker.js"), and postMessage of cloneable data. That is what community writeups do. It is not “pass this Compose lambda into MapLibre’s pool.”

Kotlin/Wasm: a second runtime, not a thread

Official position: Wasm does not support multithreading.

• KEEP-0398 (KT-62423): “For JS/Wasm trivial single-threaded implementation can be provided.” / “Implementation for these backends will be single threaded.”
• Stdlib: AtomicInt.wasm.kt and the docs: “Since the Wasm platform does not support multi-threading, the implementation is trivial.”

A worker is a new Wasm instance with its own GC heap. JsReference is an opaque frozen JS object and is not a shared pointer (Kotlin/Wasm JS interop). Function types can cross to JS in the same realm; they cannot be structured-cloned into MapLibre’s workers.

Wasm-specific interop that matters here:

• ES modules only; no @JsNonModule.
• @JsExport is package-level functions only. You cannot export a class. registerWorkerSource wants a constructor.
• No dynamic. Experimental MapLibre worker APIs get clumsier.
• Arrays are not interop types; use JsArray / typed arrays.

KT-68453 (K/Wasm: "Supported JS engine not detected" in Web Worker, fixed in 2.0.20): the generated runner used typeof window !== 'undefined', so a Kotlin/Wasm program failed to start in a worker at all. That is fixed, so a self-hosted Wasm worker can boot. It does not make MapLibre’s importScripts path work.

That path is the Wasm killer: Kotlin/Wasm emits .mjs + .wasm. MapLibre workers are classic and call importScripts. Classic importScripts cannot load ES modules, and a Wasm program also needs async WebAssembly.instantiate. You cannot inject the Wasm runtime into MapLibre’s pool with the API they document.

People who run Kotlin/Wasm in workers (marchuk.io) spawn their own Worker("./wasmJs.js") and copy the .js + .wasm next to the app. That is a second program plus message passing, not a callback installed into MapLibre.

What this means for the two browser designs

addSourceType + worker source (callback in the worker)
Would require a second Kotlin compilation whose output is a classic script that calls self.registerWorkerSource, plus a way to get the app’s loadTile into that isolate.

• You cannot send the lambda (KEEP web-workers + structured clone).
• You cannot share Compose / coroutine / Ktor state (separate heap; KEEP-0002 says not to mix Compose and workers).
• On Wasm you also cannot importScripts the module, cannot export a WorkerSource class, and cannot share JsReferences.
• An RPC from the worker back to main just recreates addProtocol with more surface area.
• Shipping a whole second Kotlin/Wasm runtime into every MapLibre worker is a bundle-size non-starter.

addProtocol behind a vector source (current CustomVectorSource)
The handler stays on the main Kotlin runtime. That is why GlJsCustomVectorAttachment works: it registers addProtocol on the page, runs provider.loadTile with coroutines, and returns an ArrayBuffer. MapLibre still parses MVT in its workers. The Kotlin callback never leaves the isolate that owns it.

#1081 (the Wasm draft) already depends on that model: shared webMain bindings, JsAny / Promise boundaries, and “protocol failures retain the HTTP status MapLibre expects when a Kotlin/Wasm request rejects.” That is main-thread interop. A worker-source path would be a second compilation unit that PR does not have, plus classic-script output Wasm cannot produce.

CustomGeometrySource on the browser still needs an MVT encoder (spatial-k) or a GeoJSON source. That is an encoding problem, not a worker-callback problem. Putting getFeatures in a MapLibre worker does not remove the need to encode, and it adds an isolate boundary Kotlin cannot cross.

Bottom line

Today’s Kotlin has no shipped worker-callback feature. The KEEP (web-workers.md, status under consideration) and KT-45455 (obsolete) are the record of that. JS and Wasm are officially single-threaded (KEEP-0398, stdlib atomics). Wasm can run as a worker after KT-68453, but only as a separate program talking over postMessage, and not via MapLibre’s importScripts hook.

For this library, “callback in a worker” is the wrong shape for both JS and the Wasm port. Keep the provider on the main thread (addProtocol / GeoJsonSource) and treat MVT encoding as the remaining gap for CustomGeometrySource.

  

[sargunv]

I think this can be done with https://github.com/maplibre/geojson-vt and geoJSONToTile, mirroring the maplibre-native code paths