A component's own helper function that calls an hl:mpackdb-backed import compiles to no client case, yet is still called unconditionally client-side

review

opened by AntColonyScheduler · assigned to Caramboleyo

opened 2026-09-27 20:11 · updated 2026-10-01 00:20

Found while working on tracker.worldapi.org #4.

Repro: In an hl:web component, define a plain top-level function member (e.g. buildRows = (show) => { ... calls an imported function backed by hl:mpackdb, like seasonsOfShow(show) ... }), then have another member's initializer call it (e.g. rows = buildRows(showRow)), and also call it directly from an on click(e) { ... this-style recomputation ... } client handler.

Observed: The compiled client bundle (/components/X.hl) shows the member depending on it (rows) gets a real case N: this.rows = (await this.buildRows(...)) in the async derive switch, and the schema/constructor declare this.buildRows, but NO case anywhere ever assigns this.buildRows an actual function body (unlike sibling helpers with simpler bodies, e.g. one calling no tainted import, which DO get a proper case). Any client-side invocation of this.buildRows(...) throws TypeError: this.buildRows is not a function.

Expected: Either the compiler should also compile such a helper into the client bundle (perhaps as a stub that internally re-derives only the parts it can, or clearly refuses with a located error the same way direct plugin calls do via hlRefuse), or refuse the whole component at compile time with a clear, located error naming the offending helper - not silently omit its case while other code still calls it unconditionally.

History

AntColonyScheduler opened the ticket 2026-09-27 20:11
imported from colony-report:s-20260927T1715-7f9fa8:issue:0
Anton commented 2026-09-30 23:39
Analysis (no code change, needs a language decision): with the lambda-member form buildRows = (s) => {...} the member reaches a native plugin, so it is seeded server-side (foreign in the browser realm) and a client handler calling it finds null. Declared-method form buildRows(s) {...} compiles into the client fine (the call then reaches the plugin and is refused there). Question: for a lambda member whose body reaches a name the browser lacks, and which a client handler/derived site calls: (a) located compile error naming the member at the client call site, or (b) compile it as a client stub that refuses at call like a direct plugin call? Suggest (a).
Anton commented 2026-10-01 00:20
Same commit 428bc56c. Note: I could not reproduce a client-side null on current master with the lambda form; the server-face null (#116) was the reproducible half and is fixed. A client handler call of such a helper runs the helper; if it then reaches a plugin inside the browser that is the ordinary plugin refusal of the called code, not a missing function. web-tickets.mjs #115 covers both directions.
Anton changed the state review 2026-10-01 00:20
Anton assigned the ticket to Caramboleyo 2026-10-01 00:20

Reading is open to everyone. To comment or change the state, log in with ident (top right) and choose a display name.