step-journey: step-based flows as an Angular component

The problem

Multi-step procedures are everywhere: sign-ups, applications, checkouts, approval flows. And everywhere the same progress bar shows up, almost always rewritten from scratch for each project — typically as a single monolithic component mixing state calculation, dot rendering and connector lines.

The outcome is predictable: it works while the requirement stays identical, and becomes hard to touch at the first change. Adding a state, changing colours for one client, handling flows of varying length all mean reaching into a component that does too many things at once.

Design decisions

One component per concept. The journey, the individual step and the divider are separate components. This is not architectural pedantry: it is what lets you change how a step looks without risking the flow logic, and reason about each piece in isolation.

State is declarative. Callers describe the steps and their condition — completed, current, pending — and the rendering follows. No imperative DOM manipulation, no state duplicated between caller and component: a single source of truth.

Customisation per state, not per instance. Colours are set once per state and apply everywhere, or get overridden on an individual step when genuinely needed. The most common configuration is the one requiring the least code; edge cases stay possible without taxing the ordinary ones.

A demo app inside the repository. The project ships a test application that mounts the library under real conditions. It serves development as much as evaluation: you can watch it work before installing it.

The artefact

The package is published on npm and installable in any Angular project. The sources are public under the MIT licence, together with the test app that exercises them.

It is the kind of component that seems minor until you have to maintain it across five different projects — at which point the difference between one versioned library and five diverging copies becomes obvious.