ReviewOS

stacks/stx

One screen, one view: an app should not maintain a web view and a native view of the same thing

#2065
Closed glennmichael123 opened this 9 days ago ·
9 days ago

From Chris (hq.training):

im thinking too, this has to be streamlined, we should not have to maintain web && mobile views, stx needs to be smarter here, if you can please tackle that too

What it looks like in a real app today. hq.training's phone app is Craft in hybrid mode: some paths are drawn by native screens, the rest by the web view. That means every screen that went native now exists twice:

ScreenNativeWeb
Todayresources/native/Today.stxresources/views/m/index.stx
Calendarresources/native/Calendar.stxresources/views/m/calendar.stx
Progressresources/native/Progress.stxresources/views/m/progress.stx
Storeresources/native/Store.stxresources/views/m/store/index.stx
Meresources/native/Me.stxresources/views/m/me.stx
Healthresources/native/Health.stxresources/views/m/health.stx

Six screens, twelve files, written by hand against two different vocabularies — <View>/<Text>/<ScrollView> with ui.* classes on one side, <div>/<p> with Crosswind utilities on the other — reading the same stores and drawing the same data.

They drift. A fix lands in one and not the other; a guard test that reads one file passes while the other screen is wrong. Both copies have to be kept in a changelog entry, a review, and a contributor's head.

What would fix it: a screen written once that stx can render to a web document or to native views, the way a component already renders to a page. The hard parts, from the shape of the duplication above:

  • a layout vocabulary both targets can honour, rather than CSS on one side and flex-only views on the other
  • components that exist on both (a grouped list, a nav bar, a tab bar, a chart)
  • an escape hatch for the genuinely platform-specific — a native screen wants the platform's refresh control, a web page wants a URL
  • which of the two is the source when a screen cannot be expressed in the shared vocabulary

Related: #1992 asked for native views to exist at all. This is the half after that one — having them without writing everything twice.

9 days ago

Audited against current main: the one-source screen path is already shipped. compileScreenSource runs an ordinary stx template through processDirectives, resolves shared components, and translates the same rendered output into native IR; web rendering uses that same stx source directly. Native render-screen coverage verifies server data, conditionals, components, bindings, events, and native primitive mapping. Verified: 82 tests passed, 0 failed. Closing as completed.

Sign in to comment on this issue.