Skip to content

PATTERN Cited by 1 source

Preloaded view flow for predictable navigation

When to use

You have an SDUI surface where the user is likely to navigate through a predictable sequence of related views — a wizard, an FAQ menu, a multi-step form, an onboarding flow — and you want to eliminate the per-navigation network round-trip while keeping each view a distinct addressable screen.

The pattern

Bundle the configurations for all likely-subsequent views in the initial response. The client navigates locally between them using a dedicated action type; no extra network request is made per navigation.

Concretely, in CHAOS:

  • A ViewBuilder exposes a subsequent_views() method that returns additional ViewBuilder classes:
def subsequent_views(self) -> List[Type[ViewBuilderBase]]:
    return [ViewTwoBuilder, ViewThreeBuilder]
  • The framework builds each subsequent view alongside the primary and packs them into the same chaosView.views array. initialViewId points to the entry view.
  • Components use a chaos.open-subsequent-view.v1 action to navigate by viewId:
{
  "__typename": "ChaosJsonAction",
  "identifier": "open-subsequent-one",
  "actionType": "chaos.open-subsequent-view.v1",
  "parameters": "{\"viewId\": \"consumer.view_two\"}"
}
  • The client switches its rendered view to the specified viewId from the already-loaded views array — zero network traffic per hop.

Verbatim (2025-07-08): "Each view builder in this list is constructed alongside the primary view builder and stored in the 'ChaosView - views' list within the final configuration. This design allows developers to define sequences of views, known as 'flows,' which are interconnected using the 'OpenSubsequentView' action. This approach is particularly beneficial in scenarios where users need to navigate quickly through a series of closely related content. By preloading these views, we eliminate the need for additional network requests for each view configuration, thereby enhancing the user experience by reducing latency."

Canonical example (Yelp for Business)

Yelp's Yelp for Business mobile app uses a CHAOS Flow to power a customer support FAQ menu. Each page of the FAQ is its own view; transitions between them are open-subsequent-view actions. The user perceives instant navigation because the entire FAQ tree is delivered in one CHAOS response.

Simplified three-view example (from the post)

View 1  ──[Next]──▶  View 2  ──[Next]──▶  View 3  ──[Back to start]──▶  View 1

All three views, all three buttons, all three open-subsequent-view.v1 actions arrive in one GraphQL response. The client's switch between them is a local viewId lookup.

When not to use this pattern

  • Unpredictable navigation. If the user might go anywhere from the current view, preloading all destinations is wasteful. Use lazy loading with view placeholders or regular per-view fetches.
  • Large views. Preloading amortises round-trips but inflates the initial payload. A view with megabytes of content or hundreds of components shouldn't be bundled with many others.
  • Data-fresh views. Preloaded configurations are as fresh as the moment of the parent request. Views that need to reflect real-time state (prices, availability) should be fetched on navigation.
  • Auth-gated branches. If a subsequent view requires a different auth scope or a fresh credential, preloading leaks an unauthorised view into the client.

Trade-offs with adjacent patterns

Preloaded view flow View placeholder Per-navigation fetch
Network cost one round trip for many views one per placeholder resolution one per navigation
Staleness risk low (all views from same request) minimal (per placeholder) none
Payload size large (all views upfront) medium minimal
UX on navigation instant loading spinner, then content full loading state
Good for wizard / FAQ / onboarding nested widgets on home screen ad-hoc navigation

Hard problems

  • Deciding which views to preload. Overly greedy preloading wastes bandwidth; overly conservative preloading defeats the purpose. subsequent_views() puts the decision in the view builder — usually based on domain knowledge.
  • Memory on client. The client must keep every preloaded view resident in memory while the flow is active.
  • Consistency with regular views. A viewId that's both a preloaded subsequent view and a top-level view for other entry points must produce identical configuration either way.

Seen in

Last updated · 476 distilled / 1,218 read