The widget that has to carry two tables

Three sentences

Every chart in the library is reached from R by one function that hands the chart a single table of results plus a list of settings, and two charts do not fit that shape — the survival chart, which composes its endpoint from a table of events and a table of the population at risk, and the participant profile, which draws one participant at a time in response to a click somewhere else on the page. Both have sat as recorded deferrals since the library's last release, each citing the requirement this page answers, and neither can be built until somebody says what the R function should look like. This page builds all four candidate shapes, runs them, and reports what each one actually did — including the two failures that happen quietly, which are the reason this is a decision rather than a mechanical wrap.

Four things executed rather than reasoned about

Everything below was run in this session against the safety R package's integration branch, with the chart library bundle it actually ships. Nothing here is read off a specification.

One — the survival chart under today's contract builds cleanly and draws an error

We wrote the obvious binding: hand the survival chart the events table as the one table the contract allows. R accepted it. It accepted it again when we replaced every column name in the settings with a name that does not exist in the data. The same nonsense handed to any of the eleven working charts is refused immediately.

The cause is not laxness. The shared check reads the list of required columns from one specific place in each chart's data contract — the part that describes a chart with a single table. A two-table contract describes its required columns per table instead, so the check looks in a place that is empty, finds nothing to check, and reports success.

Loaded into a browser, the widget that R had just declared healthy rendered a single line of red text: Required dataset(s) missing: events, population — pass { events, population } arrays of records. The chart library caught what the R package did not.

Two — a second table put where the profile already puts its own arrives unusable, and nothing says so

The participant profile already reads a second domain: it draws a participant's adverse events beneath their laboratory results, and the chart library takes those records inside the settings object rather than as a second table. That looked like a free answer — carry the second table in the settings and change no signatures at all. It is not.

R serialises a table of data column by column. The one table the binding names is converted back into records in the browser by the binding itself; a table hidden inside the settings is not, so it arrives as an object of columns where the chart expects a list of rows. The chart tests for a list of rows, finds an object, and skips the whole domain without an error, a warning, or a mark on the page.

This is the same class of defect as the first one, arrived at from the other direction, and it is why the settings route is not a shortcut.

Three — the participant profile alone on a page shows nothing at all

We built the profile widget properly: correct contract, correct column checks, real laboratory data, no errors anywhere. Loaded in a browser it rendered an empty control panel and one line of text — Waiting for selection — listening on document.

The profile is a drill-down. It waits for another chart on the page to announce which participants a reviewer picked, and in a standalone R report there is no other chart. This, and not the number of tables, is the real reason the profile has no binding. Its data contract declares one table, and always has.

Four — the profile is already on screen in eight of the eleven widgets, and nothing says so

Looking for where the profile does get its selection, we found that eight of the eleven widgets the package ships today already carry it, mounted as a panel beside the chart, switched on by default. Opening the liver-safety widget from R with its own documented example and clicking a participant produces the full profile — header, demographics, the R ratio, the standardised laboratory trajectory, the measure table with sparklines — with no new code and no change to anything.

None of this is written down. The setting that controls it is not in any of the vendored data contracts, so it is undocumented, on by default, and invisible to the checks. The measurement, taken from the bundle the package actually ships:

Which sharpens the profile question rather than answering it. A reviewer inside the liver widget sees a participant's laboratory story; one inside the adverse-event widget sees their event story; nobody sees both, because a host chart only feeds the profile the domain it holds itself. Both domains together is exactly what a standalone widget would be for.

What each way of carrying two tables actually costs

Not a proposal — it renders

We implemented the named-tables shape end to end and ran it. The survival chart draws from R: 254 participants across three treatment arms, 217 events and 37 censored, confidence bands, censor marks, the at-risk table, and the filters that compose the endpoint live.

Every failure the naive shape swallowed is now refused before a browser is involved:

And the eleven working widgets do not notice the change:

The six are all one thing: four roster lists that name the eleven widgets by hand and now name thirteen — the export list, the deferral list, the gallery, and the example pages. Not one assertion belonging to an existing chart changed from passing to failing. The pipeline half works too: a two-table report workflow, declaring both domains the way every risk-indicator workflow in the ecosystem already declares two, ran start to finish and wrote its HTML report.

The profile, given the participants to show and both of its domains, draws both — laboratory trajectory, adverse-event summary, adverse-event timeline on the same study-day axis, and a stepper through the selected cohort.

Four, and only the first one blocks both charts

On each answer

• Answering W1 alone unblocks the survival chart. It is otherwise mechanical: the shape is built, the tests are green, the report workflow runs, and the population data exists.
• W1 and W2 together unblock both charts, close the two recorded deferrals, and take the safety R package to full coverage of the chart library — thirteen charts, thirteen bindings.
• W3 decides whether the release also ships a fifth example dataset, and whether the survival chart's example is one line or a derivation.
• W4 decides whether the release is checked by seeing it or by counting files. It does not block the other three; it decides how much the green build is worth.

Five, and two of them changed the recommendation

• The requirement, and the deferral list, and the brief that commissioned this page all say the participant profile needs two tables. Its published data contract declares one, and always has. Its second domain is optional and its blocker is the selection, not the tables. This is what turned W2 from a plumbing question into a product one.
• The requirement says the survival chart "needs no design beyond the established pattern". It is the one that does. The established pattern applied to it produces a widget that builds silently and draws an error.
• The requirement lists re-vendoring the chart library as outstanding work. It was done three weeks ago: the package already declares and ships the current release, and both charts are already inside the bundle. Nothing upstream is waiting.
• The requirement lists vendoring the adverse-event and population extracts as outstanding. The adverse-event extract has shipped since the package's first widget release in July. Only the population extract is missing, and it is 254 rows and four columns.
• The requirement's body targets a release that has since been cut twice over; its own title names the right one. The work lands in the release after the two candidates currently in your queue.

One claim we expected to find wrong and did not: the shared binding helper genuinely does validate every one-table chart properly, and the eleven are in good order. The defect is confined to the shape nothing has used yet.