Architecture

Stages consists of two main components, Stages and Form. The philosophy of Stages is to not render any markup, that is your job. Stages handles all the complicated stuff like validation for you, but you have to bring your own markup and styles and field components. This assures 100% flexibility, but it takes a little bit more effort initially when setting up your project.

Stages has been highly inspired by libraries like Radix and Beautiful-DnD and uses render props and component composition for maximum flexibility. It originated from a wizard we've built at Unic for a big client project, a wizard which was highly dynamic and demanded high flexibility from the wizard setup.

Design Goals

To summarizy the design goals:

  • The two main components, Stages and Form, don't render anything, they just give you render props
  • Configuration and rendering is always separated
  • Configuration is always dynamic, not static
  • Everything can be ovrwritten per field if needed, like validation, error rendering, visibility etc.
  • No component framework lockin, you can bring your own UI/Form components
  • Define the resulting data structure however you want, with deep nesting and custom typecasting

API best practices followed:

  • Named parameters pattern (one object in callbacks)
  • Consistency (same properties on similar fields, options for select, radio group, …)
  • Fluid API (accept strings, arrays, callbacks for example in casting props)

Basic Component Structure

Architecture

You can use the Form component without the Stages component.