Skip to content

feat: table/database view over page properties #228

Description

@tstapler

Problem

SteleKit has no editable grid/database view over a set of pages' properties. Trilium Notes' Table collection (https://docs.triliumnotes.org/user-guide/collections/table) is its flagship differentiator vs. plain outliners: property columns editable inline, sortable, with optional tree nesting — the same category of feature as Notion databases / Anytype sets.

SteleKit already stores page properties (Logseq key:: value first-block syntax) and has the underlying tag/reference data to group pages by. No existing project_plans/ entry covers a table view (checked graph-sections/graph-namespaces — those are about sync partitioning, not a UI view).

Why this matters

  • Turns "a set of pages sharing a tag" into a spreadsheet-like, at-a-glance, editable surface — useful for reading lists, project trackers, contact lists, etc. without leaving the graph.
  • Natural downstream consumer of the live-query executor (feat: execute {{query}} blocks as live, auto-updating results #224 in this repo) — a table view is essentially "query results rendered as a grid" rather than a list.

Suggested scope (v1)

  • Define a table over a tag/query (e.g. all pages tagged #book).
  • Columns = page properties present on those pages; inline-editable cells for text/number/date/checkbox/link-type properties.
  • Column show/hide, reorder, sort.
  • Out of scope for v1: tree-nested rows (parent/child pages within the table), bulk column rename propagation, saved multiple table views per tag.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions