Extend notebook Inputs.table parity with filtering and larger-data presentation #140

New issue

Open

opened 2026-05-29 13:07:43 +00:00 by steve · 0 comments

steve commented

2026-05-29 13:07:43 +00:00

Owner

Problem

The notebook runtime now supports Inputs.table(...) for row selection and sortable headers, which is enough for the current System Guide fixture. The parity audit still calls out broader table interactions as unfinished work, especially filtering and larger-data presentation. Without an explicit issue, the remaining gap is underspecified and easy to lose while the current implementation remains intentionally small and notebook-owned.

Goal

Define and implement the next incremental Inputs.table(...) parity slice that improves discoverability and usability for larger datasets without turning the notebook runtime into a full spreadsheet or virtualized grid system.

Scope

Audit the upstream Observable Inputs.table(...) behavior relevant to filtering, sorting combinations, and larger datasets.
Decide which table interaction improvements belong in the next notebook-owned parity slice, with filtering as the leading candidate.
Implement the chosen interaction surface inside @lapis-notes/notebook-input while preserving stable serializable values and the current selection semantics.
Extend focused tests and System Guide acceptance coverage to exercise the new table behavior.
Update parity/runtime docs to describe the supported interaction surface and any explicit limits.

Non-goals

Do not implement spreadsheet-style editing, formula cells, column reordering, or arbitrary inspector configuration.
Do not add premature virtualization complexity unless a concrete larger-data requirement proves the current renderer insufficient.
Do not change persisted input values in a way that breaks existing notebook state restoration.
Do not fold unrelated layout-helper or dataset work into this issue.

Acceptance Criteria

The parity audit documents the expanded Inputs.table(...) contract and any intentionally unsupported table features.
The chosen interaction improvements work with attachment-derived row data and preserve downstream reactivity.
Focused unit or runtime tests cover filtering or the selected larger-data behavior.
Workspace acceptance exercises the new table interaction in the markdown-native System Guide fixture or a sibling fixture.
Documentation explains when notebook authors should use the enhanced table surface and where limits still remain.

Implementation Notes

Keep the table behavior notebook-owned and incremental; do not pull in a general-purpose data-grid dependency unless the current implementation becomes a blocker.
Preserve original-row identity so sort and filter state do not break selected-value serialization.
Favor the smallest interaction slice that materially improves System Guide parity.

Suggested Files or Specs To Inspect

packages/notebook/input/src/ui-runtime.ts
packages/notebook/input/src/styles.css
packages/notebook/src/lib/runtime/**
packages/workspace/e2e/notebook-system-guide.spec.ts
e2e-vault/plugin-notebook/System Guide.notebook.md
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-input check
pnpm --filter @lapis-notes/notebook exec vitest run src/lib/runtime/__tests__/notebook-worker.test.ts
pnpm --filter @lapis-notes/workspace test:e2e -- e2e/notebook-system-guide.spec.ts --project chromium
pnpm test:smoke

Follow-up Tasks

Reassess whether larger-data presentation needs virtualization only after filtering and acceptance coverage land.
If broader parity remains out of scope, document the notebook-owned table contract more explicitly for authors.

Implementation Summary

Populate when closing the issue.

Track the next table-parity slice after row selection and sortable headers so the remaining Observable-style data-table gap is explicitly scoped instead of left as an informal note in the parity audit. ## Problem The notebook runtime now supports `Inputs.table(...)` for row selection and sortable headers, which is enough for the current System Guide fixture. The parity audit still calls out broader table interactions as unfinished work, especially filtering and larger-data presentation. Without an explicit issue, the remaining gap is underspecified and easy to lose while the current implementation remains intentionally small and notebook-owned. ## Goal Define and implement the next incremental `Inputs.table(...)` parity slice that improves discoverability and usability for larger datasets without turning the notebook runtime into a full spreadsheet or virtualized grid system. ## Scope - Audit the upstream Observable `Inputs.table(...)` behavior relevant to filtering, sorting combinations, and larger datasets. - Decide which table interaction improvements belong in the next notebook-owned parity slice, with filtering as the leading candidate. - Implement the chosen interaction surface inside `@lapis-notes/notebook-input` while preserving stable serializable values and the current selection semantics. - Extend focused tests and System Guide acceptance coverage to exercise the new table behavior. - Update parity/runtime docs to describe the supported interaction surface and any explicit limits. ## Non-goals - Do not implement spreadsheet-style editing, formula cells, column reordering, or arbitrary inspector configuration. - Do not add premature virtualization complexity unless a concrete larger-data requirement proves the current renderer insufficient. - Do not change persisted input values in a way that breaks existing notebook state restoration. - Do not fold unrelated layout-helper or dataset work into this issue. ## Acceptance Criteria - The parity audit documents the expanded `Inputs.table(...)` contract and any intentionally unsupported table features. - The chosen interaction improvements work with attachment-derived row data and preserve downstream reactivity. - Focused unit or runtime tests cover filtering or the selected larger-data behavior. - Workspace acceptance exercises the new table interaction in the markdown-native System Guide fixture or a sibling fixture. - Documentation explains when notebook authors should use the enhanced table surface and where limits still remain. ## Implementation Notes - Keep the table behavior notebook-owned and incremental; do not pull in a general-purpose data-grid dependency unless the current implementation becomes a blocker. - Preserve original-row identity so sort and filter state do not break selected-value serialization. - Favor the smallest interaction slice that materially improves System Guide parity. ## Suggested Files or Specs To Inspect - `packages/notebook/input/src/ui-runtime.ts` - `packages/notebook/input/src/styles.css` - `packages/notebook/src/lib/runtime/**` - `packages/workspace/e2e/notebook-system-guide.spec.ts` - `e2e-vault/plugin-notebook/System Guide.notebook.md` - `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-input check pnpm --filter @lapis-notes/notebook exec vitest run src/lib/runtime/__tests__/notebook-worker.test.ts pnpm --filter @lapis-notes/workspace test:e2e -- e2e/notebook-system-guide.spec.ts --project chromium pnpm test:smoke ``` ## Follow-up Tasks - Reassess whether larger-data presentation needs virtualization only after filtering and acceptance coverage land. - If broader parity remains out of scope, document the notebook-owned table contract more explicitly for authors. ## Implementation Summary Populate when closing the issue.

steve added the

labels

2026-05-29 13:07:43 +00:00