Assess and size a full port of AtomicServer TablePage to ELFA Tables #77

New issue

Open

opened 2026-10-28 18:08:16 +01:00 by michielbdejong · 0 comments

michielbdejong commented

2026-10-28 18:08:16 +01:00

Owner

Goal

Assess the feasibility and effort of porting the existing AtomicServer table experience into ELFA Tables on NextGraph. So far this repository has largely developed its table UI from scratch. We still want to consider a full port-over of the upstream implementation rather than assume that continuing the separate implementation is preferable.

This issue is an investigation and sizing exercise, not a decision to port only the grid or authorization to replace the current app wholesale. ELFA Tables is the current priority; its initial implementation was merged in #70. See docs/ROADMAP.md.

Starting point

Inspect AtomicServer's TablePage, TableResource, useTableData, and TableEditor/FancyTable together, including their transitive dependencies. The Data Browser lazy-loads TablePage as a build chunk; it is not currently a standalone reusable package. Reference inspected source: github.com/ontola/atomic-server@49d21e08f7/browser/data-browser/src (confirm the appropriate revision when beginning).

The page receives an Atomic Resource prop and inherits Atomic Store access and application contexts. The full experience includes schema/property editors, typed cells, saved views, filters/sorting/paging, aggregates, row operations, history/undo, presence, comments and alternative views. Inventory actual dependencies and distinguish essential table behavior from optional integrations; do not infer an extraction boundary from the lazy-load boundary.

Investigation and expected output

Map the upstream module/dependency graph and Atomic Resource/Store operations: queries, reactive subscriptions, saves, creation/deletion, schema metadata, permissions and identity, including assumptions about local persistence and remote synchronization.
Compare those contracts with native NextGraph records/ORM and useDiscrete schema/view metadata. Identify reusable code, adapters, refactoring and missing backend capabilities; avoid assuming Atomic and NextGraph have interchangeable storage APIs.
Identify router use separately from other Data Browser services. It currently supports active saved view/history, column-edit dialog state and opening linked resources/forms. Consider a host-supplied route-state/navigation interface: the db-app-runner frontend can read/write browser location/history, while embedded hosts can supply their own navigation. Preserve reactive Back/Forward and deep-link behavior.
Inventory Data Browser contexts and UI dependencies, including dependencies pulled in through editors/dialogs. Separate host services from the table implementation and identify what is needed to run outside the Data Browser.
Compare a full TablePage port with extracting the shared table implementation upstream and with the existing local implementation. Include feature coverage, maintenance/upstream update strategy, licensing/attribution and dependency-version constraints. A FancyTable-only option may be a comparison, not a substitute for assessing the full port.
Give an effort breakdown, risks, open decisions and a recommended staged proof of concept. Distinguish already demonstrated behavior from estimates. Link the separate iframe-custom-view investigation because a full port may include that host boundary.

Validation expectations for a subsequent PoC

Use actual upstream UI against native NextGraph data. Verify loading, editing, creation/deletion, schema changes, query scope and paging, saved views, retained drafts/conflicts and error behavior for the selected slice. Preserve the bounded-query and performance requirements tracked in #52; do not silently fall back to full-collection loading. State unsupported features explicitly. No full port is claimed complete by creating this issue.

Related investigation: #78 — Investigate iframed custom views for ELFA Tables and db-app-runner.

## Goal Assess the feasibility and effort of porting the existing AtomicServer table experience into ELFA Tables on NextGraph. So far this repository has largely developed its table UI from scratch. We still want to consider a full port-over of the upstream implementation rather than assume that continuing the separate implementation is preferable. This issue is an investigation and sizing exercise, not a decision to port only the grid or authorization to replace the current app wholesale. ELFA Tables is the current priority; its initial implementation was merged in #70. See docs/ROADMAP.md. ## Starting point Inspect AtomicServer's `TablePage`, `TableResource`, `useTableData`, and `TableEditor/FancyTable` together, including their transitive dependencies. The Data Browser lazy-loads TablePage as a build chunk; it is not currently a standalone reusable package. Reference inspected source: https://github.com/ontola/atomic-server/tree/49d21e08f7a0851c7db18af404b9be318d311030/browser/data-browser/src (confirm the appropriate revision when beginning). The page receives an Atomic Resource prop and inherits Atomic Store access and application contexts. The full experience includes schema/property editors, typed cells, saved views, filters/sorting/paging, aggregates, row operations, history/undo, presence, comments and alternative views. Inventory actual dependencies and distinguish essential table behavior from optional integrations; do not infer an extraction boundary from the lazy-load boundary. ## Investigation and expected output - Map the upstream module/dependency graph and Atomic Resource/Store operations: queries, reactive subscriptions, saves, creation/deletion, schema metadata, permissions and identity, including assumptions about local persistence and remote synchronization. - Compare those contracts with native NextGraph records/ORM and useDiscrete schema/view metadata. Identify reusable code, adapters, refactoring and missing backend capabilities; avoid assuming Atomic and NextGraph have interchangeable storage APIs. - Identify router use separately from other Data Browser services. It currently supports active saved view/history, column-edit dialog state and opening linked resources/forms. Consider a host-supplied route-state/navigation interface: the db-app-runner frontend can read/write browser location/history, while embedded hosts can supply their own navigation. Preserve reactive Back/Forward and deep-link behavior. - Inventory Data Browser contexts and UI dependencies, including dependencies pulled in through editors/dialogs. Separate host services from the table implementation and identify what is needed to run outside the Data Browser. - Compare a full TablePage port with extracting the shared table implementation upstream and with the existing local implementation. Include feature coverage, maintenance/upstream update strategy, licensing/attribution and dependency-version constraints. A FancyTable-only option may be a comparison, not a substitute for assessing the full port. - Give an effort breakdown, risks, open decisions and a recommended staged proof of concept. Distinguish already demonstrated behavior from estimates. Link the separate iframe-custom-view investigation because a full port may include that host boundary. ## Validation expectations for a subsequent PoC Use actual upstream UI against native NextGraph data. Verify loading, editing, creation/deletion, schema changes, query scope and paging, saved views, retained drafts/conflicts and error behavior for the selected slice. Preserve the bounded-query and performance requirements tracked in #52; do not silently fall back to full-collection loading. State unsupported features explicitly. No full port is claimed complete by creating this issue. Related investigation: #78 — Investigate iframed custom views for ELFA Tables and db-app-runner.

michielbdejong referenced this issue

2026-10-28 18:08:17 +01:00

Investigate iframed custom views for ELFA Tables and db-app-runner #78

michielbdejong referenced this issue

2026-10-30 12:03:59 +01:00

Consume the Atomic table package with native NextGraph views and schema workflows #80