Context
Screenplay's layout arrangement construct (flow with when overrides;
freeform with per-width/height-class variants) needs a runtime
implementation in Scene.Engine/Scene.React that actually reflows or
re-places content based on the active width/height size class.
Proposal
flow: implement neutral primitives (row, column, grid,
grow, gap, span) mapped to CSS flex/grid in Scene.React, with
when width <class> / when height <class> producing layout overrides
evaluated against the current runtime size class — not raw pixel
breakpoints.freeform: implement variant selection keyed by the current
(width class, height class) pair, falling back predictably (and
warning, per the language design) when a targeted size class has no
matching variant.- Both arrangement modes should be able to coexist per slot within one
layout (pending the language-side decision on this) — the engine should
not assume a layout is uniformly one mode.
- Size-class computation itself (mapping actual viewport/window/device
dimensions to compact/regular) needs to live here, shared by every
renderer, so Scene.React and any future native renderer agree on
when a class boundary is crossed.
Open questions
- Whether size-class computation should be reactive (recompute on resize,
live in Studio's preview) vs. fixed per launch (mobile devices, where
orientation change is the only runtime variable) — likely both, but
worth confirming the API shape handles both cases uniformly.
Dependencies
Depends on
Blocks
Size-class computation lands here and is shared by every renderer, so Scene.React and any future native renderer agree on class boundaries.
Part of the screen work — build order and full dependency map: #7
Implementation notes
Lands in Scene.Engine (TypeScript) — size-class computation and variant selection are runtime concerns that both Scene.React and any future native renderer share, so they must sit in the engine and not in a renderer.
The layout shape (the template tree, variants, placements) is part of the C# Scene.Model and its TypeScript mirror; the evaluation of it is the engine. See #1.
Context
Screenplay's layout arrangement construct (
flowwithwhenoverrides;freeformwith per-width/height-classvariants) needs a runtimeimplementation in
Scene.Engine/Scene.Reactthat actually reflows orre-places content based on the active width/height size class.
Proposal
flow: implement neutral primitives (row,column,grid,grow,gap,span) mapped to CSS flex/grid inScene.React, withwhen width <class>/when height <class>producing layout overridesevaluated against the current runtime size class — not raw pixel
breakpoints.
freeform: implement variant selection keyed by the current(width class, height class)pair, falling back predictably (andwarning, per the language design) when a targeted size class has no
matching
variant.layout (pending the language-side decision on this) — the engine should
not assume a layout is uniformly one mode.
dimensions to
compact/regular) needs to live here, shared by everyrenderer, so
Scene.Reactand any future native renderer agree onwhen a class boundary is crossed.
Open questions
live in Studio's preview) vs. fixed per launch (mobile devices, where
orientation change is the only runtime variable) — likely both, but
worth confirming the API shape handles both cases uniformly.
Dependencies
Depends on
flowvs.freeformScreenplay#95 — theflow/freeformarrangement constructs, including the unsettled mixed-arrangement-per-slot questionBlocks
ui profileat build/run time) Stage#39 — Stage reuses size-class computation and layout unmodifiedSize-class computation lands here and is shared by every renderer, so
Scene.Reactand any future native renderer agree on class boundaries.Part of the screen work — build order and full dependency map: #7
Implementation notes
Lands in
Scene.Engine(TypeScript) — size-class computation and variant selection are runtime concerns that bothScene.Reactand any future native renderer share, so they must sit in the engine and not in a renderer.The layout shape (the template tree, variants, placements) is part of the C#
Scene.Modeland its TypeScript mirror; the evaluation of it is the engine. See #1.