solid-stage
Rich, web-friendly editor UI framework for SolidJS + TypeScript
Star 0
Fork 0
Watch
solid-stage docs feature-ideas.md
5.1 kB · 107 lines
Markdown
at main

Feature ideas #

Deferred / out-of-scope ideas. Each waits for a real second-consumer pull — a feature that lives in only one consumer stays consumer-side until a second consumer asks for it. Shipped features live in architecture.md; this file is only what we have not built.

Dock model — remaining pieces #

The movable-sections / floating-panels work shipped (drag-to-reorder, float over canvas, cross-panel + cross-stage transfer, floating panels; see architecture.md). Still deferred under it:

  • Multi-rect / predicate float regions — floatRegion is a single rect today.
  • Tabbed / stacked dock groups — sections stack vertically in a dock; no tabbed grouping.
  • Dragging side panels themselves — only floating panels move today; the static left/right panels are fixed.

Split-pane main view #

Neither consumer ships this the same way — 3d-model-exporter brokers two sibling components through App.tsx, with no shared primitive. Greenfield design driven by the next real consumer.

Multi-page navigation #

PageSelector exists only in osrs-engine-study. Greenfield in the library.

Section strip-icon bar #

A collapsed Panel currently shows only the chevron. Later: a vertical column of section icons (consumer-provided list), so a collapsed panel becomes an icon rail. Requires deciding how the consumer supplies the icon list.

This is the collapsed-strip vertical icon column — not resolved by Section's leadingAction slot (a chevron override on a floating card) or Panel's toggleVariant="edge" (an edge collapse toggle). Those are separate, shipped features. Related: the activity-bar view-router research in docs/editor-side-navigation-patterns.md (deferred indefinitely — no consumer pull yet).

Rail and panel re-siding #

From docs/editor-panel-docking-patterns.md, each waiting for a consumer to need it:

  • Rail: when a consumer has three or more mutually exclusive views on one side. Follows the router shape in docs/editor-side-navigation-patterns.md.
  • Side flip by setting: when a consumer wants a panel on the opposite side. Needs no drag.
  • Dragging panels between sides: far cheaper after a rail, by dragging its icons.

Free split layouts with a guide diamond are a non-goal: we have no layout tree to drop into.

Trailing slot after the expanded label rule #

An expanded field's (and Fieldset's) heading row is [name][info?][rule] — the .stage-field-rule is the last child, with nothing after it. A consumer may want right-anchored content on the far side of the rule: a per-group action (a reset/clear-all button, an enable-all toggle, a count badge) sitting opposite the caption, the rule filling the gap between them.

Today there's no slot for it — the rule is hard-coded last in Field's expanded branch and in Fieldset's heading. Adding it means an optional trailing-content prop (e.g. headerEnd / action) rendered after .stage-field-rule, shared by both Field (expanded) and Fieldset. The rule already flex: 1 1 0, so a trailing flex child anchors to the right for free.

Deferred until a real consumer pull (no second consumer asks yet). When built, do it once on the shared heading row so Field expanded + Fieldset get it together.

Naming pass before v1.0 (breaking) #

The public surface is consistently Stage-prefixed — CanvasStage, StageFloatHost, StageModalHost, StageToastHost, stageModal, stageToast, stageTooltip, StageSize — with one outlier: EditorPanels. It's a holdover: the v0.5.10 taxonomy refactor (a236e48) renamed EditorPanes → EditorPanels but never reconsidered the Editor prefix, which dates from the original extraction. The docs already call an EditorPanels instance "the stage", so the prose and the symbol disagree.

Do a single coordinated naming pass for v1.0 (a breaking change, so gate it there — hence here, not now). It's not a clean find-replace: settle the deeper question first, then rename everything to match in one go.

  • Decide what "stage" canonically means — the outer shell (what EditorPanels is) or the canvas viewport (what CanvasStage is). Today both claim it.
  • Then name the shell to match. StagePanels is the safe prefix-fix, but "Panels" undersells a component that also owns the bars + center; Stage is the most accurate if CanvasStage is reframed to clearly be "a canvas you drop in the centre" (e.g. it's not the stage, it's a thing in one).
  • Audit the rest of the surface while at it for any other convention drift, so v1.0 ships one coherent vocabulary.

Provide a deprecation alias for one minor cycle if practical, or just take the clean break at the major.

ESLint config #

Skipped in v1. tsc --noEmit + vitest cover what we need.

Mobile / touch support #

The library was built and tested for desktop pointer input, and touch has no deliberate design beyond section and panel drags, which work from the grip with a finger. Still open: touch hit-target sizing.