Work-area views and view engines

A view opened in a work-area tab is declared with one uniform shape — no key is privileged, and the shell has no built-in notion of “the table” or “the graph”:

{
  "views": [
    { "id": "tasks", "type": "table", "config": { "rows": { "ref": "taskRows" }, "columns": [] } },
    { "id": "graph", "type": "graph", "config": { "nodes": { "ref": "taskNodes" }, "edges": { "ref": "taskEdges" } } },
    { "id": "fleet", "type": "map",   "config": { "markers": { "ref": "vehicles" } } },
    { "id": "editor", "component": "editorView" }
  ]
}

type is the id of a view engine. The kernel registers table and graph; any plugin adds its own:

ctx.views.registerEngine({
  id: "map",
  Component: ({ config, context, bindings }) => <LeafletView ... />,
  captureState: (tabId) => ({ center, zoom }),   // optional
  restoreState: (tabId, state) => { /* reapply */ },
  cleanup: (tabId) => { /* drop resources */ },
});

A plugin using a view type provided by another plugin declares that plugin in dependsOn, so engines are registered before its views open. A view whose engine is missing shows a message instead of breaking the tab.

For the two engines it ships, the shell resolves the data selectors of the config ({ "ref": ... }, { "from": "slice", ... }) before handing it over. Any other type receives its config exactly as declared, plus the bindings registered with ctx.ui.define(), and resolves them itself.

captureState / restoreState plug the engine into the view-state service: the snapshot a plugin stores in its own file (ctx.views.capture(docId)) carries each view’s state — the tables’ columns, a map’s centre and zoom — and gives it back on reopening, without the plugin knowing what is inside.

The snapshot also carries the arrangement of those tabs (layout): the groups, split orientations and their relative sizes, pruned to the tabs of that one entity. ctx.views.restore rebuilds the groups before reopening the tabs, so side-by-side views come back where they were; documents already on screen keep their own arrangement, the restored one is grafted beside the active group.

A toolbar above a view is never automatic: place commands on "toolbar": "view:<pluginId>:<viewId>" and they appear at the top of that tab, with the tab’s params in the payload.