observablehq
Allow vgplot to use DuckDBClient
From https://talk.observablehq.com/t/observable-framework-using-duckdbclient-sql-with-vgplot/9676/3:
I would like to load data using DuckDBClient.sql() and display with vgplot. I am able to do this with Observable Plot:
```js
const sql = DuckDBClient.sql({ rand: FileAttachment("./rand-xy.csv") });
```
```sql id=data
SELECT * FROM rand
```
```js
display(
Plot.plot({
height: 200,
marks: [
Plot.dot(data, {
x: "x",
y: "y",
}),
],
})
);
```
but not with vgplot:
```js
const sql = DuckDBClient.sql({ rand: FileAttachment("./rand-xy.csv") });
```
```js
display(
vg.plot(
vg.height(200),
vg.dot(vg.from("rand"), {
x: "x",
y: "y",
})
)
);
```
@mbostock responded:
Overriding the definition of sql doesn’t work (currently) with our implementation of vgplot. You’ll need to use the SQL front matter instead.
For now, the easiest way to do this would be to provide your own definition of vg, replacing the use of the default DuckDB client in vgplot.js. That would look like this:
import * as vgplot from "npm:@uwdata/vgplot";
const db = await DuckDBClient.of({trips: FileAttachment("lib/nyc-taxi.parquet")});
const sql = db.sql.bind(db);
const coordinator = new vgplot.Coordinator();
const vg = vgplot.createAPIContext({coordinator});
coordinator.databaseConnector(vgplot.wasmConnector({duckdb: db._db}));
Not sure what else there is to do here. Maybe the vg built-in should default to consuming sql._db as its DuckDB instance rather than the internal getDefaultClient method, so that when sql is redefined on the page, vg automatically inherits the altered definition?
Or is it sufficient to just have people redefine vg if they also want to redefine sql as shown in https://github.com/observablehq/framework/issues/1598#issuecomment-2319374786?
🤔 I think my expectation was being able to use vg the same way as Plot. I don't know if / think this would be a common case. The workaround is fine and non-intrusive, so happy to use it.
This originally came about because we had a page with Plots we wanted to use a brush to control, and since vg has one, we used a vg graph rather than rewrite existing stuff. Definitely not a common case, and the workaround is great (and I guess will be obsoleted by #5).
