malloy-html-data-app-runtime

HTML Data App Runtime

Publisher.query(modelPath, malloy) returns an array of plain row objects. Build the Malloy string, let the model do the work, and render the rows with whatever front-end code you like.

The runtime loads from the root-relative <script src="/sdk/publisher.js"> and adds one global, window.Publisher.

The query contract

Call	Returns	Use for
Publisher.query(modelPath, malloy, opts?)	Promise<Array> of rows	driving your own charts and tables
Publisher.queryFull(modelPath, malloy, opts?)	Promise<MalloyResult>	handing to <malloy-render>

• modelPath is the model FILE path within the package, with / separators ("subscriptions.malloy", "models/events.malloy"). It is not the source name.
• malloy is any query string, written in standard Malloy. This skill covers only the JavaScript glue, not Malloy syntax.
• opts (all optional): sourceName, queryName (queryName runs a saved query, with sourceName qualifying the source a view hangs off; sourceName on its own is a 400), givens (a { name: value } map bound to the model's Malloy given: runtime parameters for this query; safe parameterization, values are bound by Publisher server-side, not string-interpolated), filterParams (values for the model's legacy #(filter) source filters), bypassFilters, and environment / package (only if the page is served from outside /environments/<env>/packages/<pkg>/). givens and filterParams compose (both apply).

Structure the app as modules, not one inline script

Past a single tile, an inline <script> becomes unmaintainable and untestable. Split the work, and load it without a build step: put your shared libraries first as plain globals, then one ES-module entry point that imports your own files.

<!-- Globals first: the runtime, then any vendored chart library. -->
<script src="/sdk/publisher.js"></script>
<script src="./vendor/chart.umd.js"></script>
<!-- One module entry; it imports the rest. ES modules resolve with no bundler. -->
<script type="module" src="./app.js"></script>