DEV Community

Rizwan Saleem
Rizwan Saleem

Posted on

TypeScript Unknown States in Open Banking Consent Flows

#ai #frontend #typescript #webdev

TypeScript Unknown States in Open Banking Consent Flows

Open banking frontend work is full of states that look small in the UI but carry real product trust consequences.

A consent journey can move through loading, redirecting, returning, authorising, partially authorised, expired, failed, cancelled, and retryable states. If the frontend treats those states as a loose set of booleans, the experience can quickly become confusing: a spinner that never explains itself, a success message that appears too early, or an error state that makes a recoverable journey feel broken.

TypeScript is useful here because it encourages the team to name uncertainty.

Instead of modelling a consent flow as:

isLoading: boolean
hasError: boolean
isComplete: boolean
Enter fullscreen mode Exit fullscreen mode

I prefer thinking in explicit states:

type ConsentState =
  | { status: 'idle' }
  | { status: 'starting' }
  | { status: 'redirecting-to-bank' }
  | { status: 'returning-from-bank' }
  | { status: 'authorised' }
  | { status: 'partially-authorised'; missingScopes: string[] }
  | { status: 'expired' }
  | { status: 'cancelled-by-user' }
  | { status: 'retryable-error'; message: string }
  | { status: 'blocked-error'; message: string }
Enter fullscreen mode Exit fullscreen mode

This does not solve every product problem, but it changes the engineering conversation. The team is no longer asking only “does the page work?” It can ask better questions:

  • What does the user see while they are leaving the app?
  • What happens when they come back without completing consent?
  • Which errors are safe to retry?
  • Which messages need to avoid blame or panic?
  • Which state should analytics record?
  • Which state should support or operations teams recognise later?

AI-assisted coding can speed up the component work, but it should not be allowed to flatten product risk into a generic loading/error/success pattern. In regulated or trust-sensitive journeys, human judgement still needs to review the states, labels, transitions, and fallback paths.

For React, Next.js, and TypeScript teams, the goal is not to create complicated types for their own sake. The goal is to make uncertainty visible before it becomes user confusion.

That is the difference between a UI that merely renders data and a frontend system that earns trust.

— Rizwan Saleem

Rizwan Saleem is a UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder.

Website: https://rizwansaleem.co

Internal/backlink suggestions

  • Link from a future Frontend Engineering or Open Banking article hub on rizwansaleem.co.
  • If published on DEV.to, Hashnode, Medium, or Substack, include one natural canonical backlink to https://rizwansaleem.co in the author footer.
  • Cross-link later to drafts about accessible loading states, open banking frontend risk, and AI-assisted frontend testing.

Top comments (0)