HSLG Media

VenueScreens.js

VenueScreens.js

Source file: packages/app-ui/src/legacy/VenueScreens.js

Module: package-app-ui

Size: 37 lines

SHA-256: dd932b008febaa12b774d5ee904b0d228045684645e7e7842cf42258f04d5b1d

Responsibility

Owns the shared customer screens, interactions, styles and approved brand assets.

Declared entry points

  • reviewIds — source line 3.
  • reviewBrandLogos — source line 5.
  • applyReviewPalette — source line 15.
  • setVenue — source line 16.
  • nav — source line 17.
  • home — source line 18.
  • venueOptions — source line 25.
  • toggleVenue — source line 26.
  • menu — source line 27.
  • rewards — source line 28.
  • summary — source line 29.
  • points — source line 34.
  • remaining — source line 35.

Imports and dependencies

No direct import declarations detected in this file.

Behaviour and audit locations

Review control flow and returned values in the named source file; no special integration marker was detected.

Venue and content views

Venue screens render branded locations and editorial journeys using the shared application. Venue selection must change displayed branding and service context consistently, while preserving the rule that one order belongs to one venue. The native runtime cannot use sample presenter content as real booking, event or reward data. Any new editorial content provider should remain behind the REST content boundary and be tested for missing/unpublished records and incorrect venue association.

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.