Decide and implement Observable-style table input parity for notebooks #131

New issue

Closed

opened 2026-05-27 16:01:34 +00:00 by steve · 0 comments

steve commented

2026-05-27 16:01:34 +00:00

Owner

Problem

The current notebook runtime supports lapis.FileAttachment(path).csv() / .tsv() and can render tabular attachment data through lapis.table(...). The remaining System Guide gap is Inputs.table(...): users reading Observable examples do not yet know whether Lapis supports that name as a selectable input control, a display-only compatibility shim, or intentionally steers notebook authors to the existing lapis.table(...) dataframe renderer.

Goal

Define and ship the smallest table parity surface that makes attachment-driven System Guide examples understandable in Lapis notebooks without replacing notebook-owned dataframe rendering or importing Observable's inspector/runtime model.

Scope

Audit the Observable System Guide Inputs.table(...) examples and choose the Lapis-supported contract for the first parity slice.
If direct Inputs.table(...) support is chosen, implement it inside @lapis-notes/notebook-input as a DOM-backed notebook input that accepts array/object row data, preserves DSV column order when available, emits stable input/change events, and exposes a serializable .value for downstream cells.
If direct Inputs.table(...) is not chosen for this slice, document the compatibility decision clearly and make lapis.table(...) the explicit supported table display surface for attachment-driven examples.
Reuse the existing notebook-owned dataframe/table rendering behavior where practical instead of building an Observable inspector clone.
Extend the markdown-native System Guide fixture or add a sibling fixture so the chosen table surface is covered end to end.
Add focused unit coverage for the chosen table surface, including DSV rows loaded from FileAttachment(...).csv({ typed: true }).

Non-goals

Do not add arbitrary remote file access beyond the current notebook-relative vault attachment rules.
Do not replace the notebook-owned dataframe renderer with a raw Observable table inspector.
Do not broaden this issue into general notebook import, fetch, or dataset-globals semantics.
Do not implement advanced table interactions such as full spreadsheet editing, cross-cell table virtualization contracts, or arbitrary Observable inspector options unless they are required by the selected first-slice contract.

Acceptance Criteria

The notebook parity audit explicitly states whether Inputs.table(...) is supported directly or whether lapis.table(...) is the supported Lapis table parity surface.
The chosen table surface works with rows returned by notebook-relative FileAttachment(...).csv({ typed: true }) without manual JSON conversion in fixture code.
If Inputs.table(...) is supported, changing the table selection or value updates downstream dependent cells through the existing notebook input protocol.
Focused unit tests cover the chosen table surface and DSV column-order preservation.
Workspace acceptance covers at least one attachment-driven tabular example derived from the System Guide parity surface.
The runtime docs describe authoring guidance for attachment-driven table examples.

Implementation Notes

Keep ownership of rendered table behavior in the notebook packages, even if Inputs.table(...) becomes a compatibility alias or wrapper.
Prefer serializable selected-row or selected-row-list values for any input form so persisted input state remains durable.
If the first slice chooses lapis.table(...) instead of direct Inputs.table(...), close the parity loop with explicit documentation and acceptance coverage rather than leaving the choice implicit.

Suggested Files or Specs To Inspect

packages/notebook/input/src/**
packages/notebook/src/lib/runtime/**
packages/notebook/src/lib/render/dataframe/**
e2e-vault/plugin-notebook/**
spec/src/20-packages/plugins/notebook/documents-and-runtime.md
spec/src/20-packages/plugins/notebook/observable-system-guide-parity.md

Validation Commands

pnpm --filter @lapis-notes/notebook exec vitest run
pnpm --filter @lapis-notes/workspace exec playwright test e2e/notebook-system-guide.spec.ts
make spec-lint
pnpm test:smoke

Follow-up Tasks

Evaluate additional attachment helpers such as image decoding only after tabular loaders are stable.
Consider richer table controls such as filtering, sorting, or multi-select only after the first parity contract is stable.

Implementation Summary

Added direct Inputs.table support for CSV-backed row selection with runtime and Playwright coverage.

Settle the remaining table-surface gap between Observable's System Guide examples and the Lapis markdown-native notebook runtime now that notebook-relative CSV/TSV attachment loading and notebook-owned dataframe rendering are already supported. ## Problem The current notebook runtime supports `lapis.FileAttachment(path).csv()` / `.tsv()` and can render tabular attachment data through `lapis.table(...)`. The remaining System Guide gap is `Inputs.table(...)`: users reading Observable examples do not yet know whether Lapis supports that name as a selectable input control, a display-only compatibility shim, or intentionally steers notebook authors to the existing `lapis.table(...)` dataframe renderer. ## Goal Define and ship the smallest table parity surface that makes attachment-driven System Guide examples understandable in Lapis notebooks without replacing notebook-owned dataframe rendering or importing Observable's inspector/runtime model. ## Scope - Audit the Observable System Guide `Inputs.table(...)` examples and choose the Lapis-supported contract for the first parity slice. - If direct `Inputs.table(...)` support is chosen, implement it inside `@lapis-notes/notebook-input` as a DOM-backed notebook input that accepts array/object row data, preserves DSV column order when available, emits stable input/change events, and exposes a serializable `.value` for downstream cells. - If direct `Inputs.table(...)` is not chosen for this slice, document the compatibility decision clearly and make `lapis.table(...)` the explicit supported table display surface for attachment-driven examples. - Reuse the existing notebook-owned dataframe/table rendering behavior where practical instead of building an Observable inspector clone. - Extend the markdown-native System Guide fixture or add a sibling fixture so the chosen table surface is covered end to end. - Add focused unit coverage for the chosen table surface, including DSV rows loaded from `FileAttachment(...).csv({ typed: true })`. ## Non-goals - Do not add arbitrary remote file access beyond the current notebook-relative vault attachment rules. - Do not replace the notebook-owned dataframe renderer with a raw Observable table inspector. - Do not broaden this issue into general notebook import, fetch, or dataset-globals semantics. - Do not implement advanced table interactions such as full spreadsheet editing, cross-cell table virtualization contracts, or arbitrary Observable inspector options unless they are required by the selected first-slice contract. ## Acceptance Criteria - The notebook parity audit explicitly states whether `Inputs.table(...)` is supported directly or whether `lapis.table(...)` is the supported Lapis table parity surface. - The chosen table surface works with rows returned by notebook-relative `FileAttachment(...).csv({ typed: true })` without manual JSON conversion in fixture code. - If `Inputs.table(...)` is supported, changing the table selection or value updates downstream dependent cells through the existing notebook input protocol. - Focused unit tests cover the chosen table surface and DSV column-order preservation. - Workspace acceptance covers at least one attachment-driven tabular example derived from the System Guide parity surface. - The runtime docs describe authoring guidance for attachment-driven table examples. ## Implementation Notes - Keep ownership of rendered table behavior in the notebook packages, even if `Inputs.table(...)` becomes a compatibility alias or wrapper. - Prefer serializable selected-row or selected-row-list values for any input form so persisted input state remains durable. - If the first slice chooses `lapis.table(...)` instead of direct `Inputs.table(...)`, close the parity loop with explicit documentation and acceptance coverage rather than leaving the choice implicit. ## Suggested Files or Specs To Inspect - `packages/notebook/input/src/**` - `packages/notebook/src/lib/runtime/**` - `packages/notebook/src/lib/render/dataframe/**` - `e2e-vault/plugin-notebook/**` - `spec/src/20-packages/plugins/notebook/documents-and-runtime.md` - `spec/src/20-packages/plugins/notebook/observable-system-guide-parity.md` ## Validation Commands ```bash pnpm --filter @lapis-notes/notebook exec vitest run pnpm --filter @lapis-notes/workspace exec playwright test e2e/notebook-system-guide.spec.ts make spec-lint pnpm test:smoke ``` ## Follow-up Tasks - Evaluate additional attachment helpers such as image decoding only after tabular loaders are stable. - Consider richer table controls such as filtering, sorting, or multi-select only after the first parity contract is stable. ## Implementation Summary Added direct Inputs.table support for CSV-backed row selection with runtime and Playwright coverage.

steve added this to the Complete Daily-Use App milestone

2026-05-27 16:01:34 +00:00

steve added the

labels

2026-05-27 16:01:34 +00:00

steve referenced this issue

2026-05-29 11:16:02 +00:00

Expand notebook FileAttachment and table helpers toward Observable System Guide data examples #134

steve changed title from ~~Expand notebook FileAttachment and table helpers toward Observable System Guide data examples~~ to Decide and implement Observable-style table input parity for notebooks

2026-05-29 11:20:48 +00:00

steve

2026-05-29 12:13:10 +00:00