DataPanel wiring — layout options

Three concrete layouts for placing the (already-built) DataPanel alongside the existing FileBrowser sidebar in App.tsx. Each shows the same scenario: a multi-file zip upload (a replication package) where the workspace contains an .RData file with multiple bindings, a CSV, and several R scripts. Goal is the spec §4.9 surface — datasets / globals / opaque per RData file — with preview and bind actions wired up.

Option A — Stacked in one sidebar (recommended) FileBrowser on top, DataPanel below
Single 220 px sidebar. FileBrowser at top renders the zip's source tree (R scripts, READMEs, PDFs — clickable to open as tabs). DataPanel below renders the workspace's data files, with RData files expanding into the datasets/globals/opaque tree per spec §4.9. Both visible whenever there's content for them. In single-file CSV mode (no zip), FileBrowser is hidden (today's behavior); DataPanel still appears with the one CSV.
interlysestatistical analysis
2 files loaded multi-file R: ready Run
Code
CodePanel
Pipeline
PipelinePanel (DAG)
Results
ResultsPanel + ArtifactsPanel

Pros

  • Stores stay independent — FileBrowser keeps reading useFilesStore, DataPanel keeps reading useWorkspaceStore. No new shared state.
  • Spec §4.9 surface is exactly what DataPanel already renders — zero rewrite.
  • Works in single-file CSV mode (no zip) — DataPanel shows alone; FileBrowser self-hides.
  • Width unchanged from today (~200–220 px) — three-panel grid keeps its proportions.

Cons

  • Same data file appears twice — once in the zip tree (controls.csv) and once in Data. Easy to filter the FileBrowser's data entries out, but a small decision.
  • Long file lists + long binding lists = lots of vertical scroll in 220 px.
Option B — Two sidebars side-by-side FileBrowser (200px) + DataPanel (240px)
Two distinct sidebars (440 px total). FileBrowser stays exactly as today. DataPanel becomes its own scrollable column to its right, always rendered when workspace files exist. Three-panel grid shrinks accordingly. Strong visual separation between "source tree" and "data bindings."
interlysestatistical analysis
2 files loaded multi-file R: ready Run
Code
CodePanel
Pipeline
PipelinePanel (DAG)
Results
ResultsPanel + ArtifactsPanel

Pros

  • Cleanest separation — "source files I edit" vs "data I bind." No mental overlap.
  • Each sidebar scrolls independently — a 200-file zip and a 50-binding RData don't fight for vertical space.
  • Smallest diff to existing code — drop the component in, leave FileBrowser alone.

Cons

  • 440 px gone before the three-panel grid starts. On a 1366-px laptop the DAG gets cramped.
  • Two adjacent vertical scrollbars look heavy.
  • Single-file CSV mode looks asymmetric — FileBrowser hidden, DataPanel alone in 240px.
Option C — Tabbed single sidebar Files / Data tabs in one 220 px column
Same width as today, but the sidebar has two tabs: Files (FileBrowser) and Data (DataPanel). User switches between source-navigation and binding-management. Auto-switches to "Data" on a fresh upload, to "Files" when the user clicks an R file.
interlysestatistical analysis
2 files loaded multi-file R: ready Run
Code
CodePanel
Pipeline
PipelinePanel (DAG)
Results
ResultsPanel + ArtifactsPanel

Pros

  • Most space-efficient — one 220 px column, both jobs available.
  • Each tab has full vertical real estate to itself.

Cons

  • Hides one view at a time. Dragging a binding to a node when you can't see the file tree (or vice versa) requires pre-switching.
  • Auto-switching adds a behavior model the user has to learn.
  • Tab UI is novel for this app — no other tabs in the chrome today.
R script data file pdf other ✓extraction complete