Type State Machine for Field Transformations

Flowcharts & More · state diagram · unknown license

This state machine illustrates how a field's type state evolves through various transformations like nullable, ID, unique, array, default, and auto-generat

Source: https://github.com/beynar/viborm/blob/08ed661ab4fb1301ca6e73f571579e83ca2ac2f8/readme/SCHEMA_ARCHITECTURE.md
Curated by beynar
State machine Type system Fluent API Data modeling Schema definition Programming Builder pattern

Mermaid source

stateDiagram-v2
    [*] --> DefaultFieldState: s.string()
    DefaultFieldState --> MakeNullable: .nullable()
    DefaultFieldState --> MakeId: .id()
    DefaultFieldState --> MakeUnique: .unique()
    DefaultFieldState --> MakeArray: .array()
    DefaultFieldState --> MakeDefault: .default(v)
    DefaultFieldState --> MakeAuto: .uuid() / .now()
    
    MakeNullable --> MakeId: .id()
    MakeId --> MakeAuto: .uuid()

What this diagram shows

A state machine depicting the progression of a field's type state from a default state through various transformations such as making it nullable, an ID, unique, an array, assigning a default value, or making it auto-generated (e.g., UUID, current timestamp).

When to use it

Useful for designing and understanding fluent APIs that modify the characteristics of a data field, ensuring type safety and valid state transitions during schema or model definition.

How to adapt it for your project

This pattern can be adapted for any builder or fluent API where an object's properties are configured step-by-step, such as database schema builders, API request constructors, or configuration object generators, by defining valid state transitions.

Key concepts