AppScreens.js
Source file: packages/app-ui/src/legacy/AppScreens.js
Module: package-app-ui
Size: 189 lines
SHA-256: 6c402ee349334ff50ff51d6eba929594ee31ca66e7211a14d06a7e5b3bda0eef
Responsibility
Owns the shared customer screens, interactions, styles and approved brand assets.
Declared entry points
$— source line 4.paths— source line 5.icon— source line 6.art— source line 7.page— source line 8.menus— source line 9.venues— source line 11.currentVenue— source line 18.total— source line 19.toast— source line 20.header— source line 21.go— source line 22.render— source line 23.auth— source line 24.form— source line 26.submit— source line 27.previous— source line 28.result— source line 32.address— source line 40.btn— source line 42.saved— source line 43.address— source line 52.button— source line 55.check— source line 56.
Imports and dependencies
No direct import declarations detected in this file.
Behaviour and audit locations
- Line 167:
* No secure data, credentials, private locations or device identifiers are shown. */ - Line 169:
sheet('Device checks', <p class="sub">Check your phone’s app features. Tests do not place orders, take payment or change your account.</p><p id="hslg-device-mode" role="
Customer screen coordination
The legacy app screen module maintains shared screen transitions and account/profile actions that the browser and native runtimes both render. A service action must return a truthful state: demonstration-only results in the presenter and real/fail-closed responses in mobile. Its global-style architecture is still technical debt; changes should be small, screen-scoped and tested against all five venue styles so that a navigation fix does not damage login-first presentation.
Relationship to the system
This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.
Change verification
Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.