Proposal: a CanvasXpress teal module for interactive clinical displays

[neuhausi]

Hi Dawid / teal team — I'm Isaac Neuhaus, author of CanvasXpress (https://www.canvasxpress.org). It's an open-source charting library with a first-class R package (GPL-3) and native support for the displays clinical reporting leans on: Kaplan-Meier with risk tables and log-rank p-values, forest plots, heatmaps, and fully interactive versions of the static tern/rtables outputs — all from reproducible, self-contained specs.

I'd like to contribute a teal.modules.canvasxpress (or fold widgets into teal.modules.general) so teal apps get interactive, hover-and-drill CDISC displays alongside the current ones. I'm offering to do the engineering and maintain it, following your module conventions. Since teal is GPL-3 and the CanvasXpress R package is GPL-3, licensing lines up cleanly.

Is a GitHub Discussion or the #teal Slack channel the right place to scope this? I can bring a working ADaM-based KM + forest-plot demo to show the integration.

Thanks,
Isaac

canvasxpress-clinical-demo.html

[llrs-roche]

Hi @neuhausi, unfortunately Dawid is no longer working on teal. I would suggest to reach out to Dony on the teal slack channel of the pharmaverse. This way it will be easier to exchange contact information and set up a meeting if needed.

We already have a module for KM and forest-plot on teal.modules.clinical. It is true that they are not interactive but that could be easily fixed. However, to support canvasXpress probably we would need to add rendering support on teal.widgets for this class/objects.

Cheers,

Lluís

[neuhausi]

Thanks Lluís — and good to know about Dawid. I'll follow up with Dony on the pharmaverse #teal Slack to exchange contact info and set up a call.

On the technical side, you've pinpointed the right seam: the cleanest path is adding a CanvasXpress render/output path in teal.widgets rather than standing up new modules. The R canvasXpress package is a standard htmlwidget with the usual shiny bindings (canvasXpressOutput() / renderCanvasXpress()), so wrapping those into a teal.widgets render/output pair — plus a settings wrapper mirroring plot_with_settings — would give tm_g_km and the forest modules an interactive target. The analyses keep producing the same data; only the final render swaps, so it stays opt-in and the existing specs/behavior are untouched.

I'm happy to do that engineering and maintain it. If it's useful to have something concrete to react to, I can open a small proof-of-concept PR against teal.widgets (a canvasXpress render/output path) with a minimal example wiring tm_g_km to it on an ADaM dataset. The demo attached above shows the KM (risk table + log-rank p) and forest displays running with no server.

Would a POC PR or a Slack call first be the better next step for you?

Thanks,
Isaac

[neuhausi]

Thanks again @llrs-roche. The public pharmaverse Slack invite link appears to have expired, so I'll loop in @donyunardi here instead — Dony, Lluís suggested I connect with you on adding an interactive CanvasXpress render path for the clinical KM/forest displays (details above). I'm happy to set up a short call or open a POC PR against teal.widgets, whichever you prefer. And if anyone can share a current #teal Slack invite, I'll gladly hop over there too.

[llrs-roche]

I've seen the demo above and the webpage. I wasn't aware of this method for interactive plots and it was interesting to see it.

Feel free to open a PR on teal.widgets. If the PR could reuse/expand on the current example it would be great. But I won't swap the default graphics made as it would alter many outcomes, but that can be discussed with Dony.

[neuhausi]

Thanks, Lluís — glad the interactive demo was useful.

I'll open a PR on teal.widgets for the CanvasXpress render/output path, and I'll build it so it reuses and extends the existing example rather than adding a parallel one. Understood on the defaults — nothing in this changes the graphics teal produces by default; the CanvasXpress render is strictly opt-in, so existing outcomes are untouched. Happy to leave any question of defaults for a later conversation with Dony.

I've also built the forest-plot bridge now (alongside the KM), so both tm_g_km- and tm_g_forest_*-style displays can go through the same render path when you want to look at them.

I'll follow up here when the PR is up.