Layoutz 0.3.2 🪶 Zero-dep Elm-style TUI’s for Haskell - now w/ terminal plots & more

Hello! Layoutz has quite some improvements including built-in granite-esque plots. Thanks for your great feedback thus far … sure you will find some more rough edges.

showcase-demo

30 Likes

As an Elm programmer I was briefly confused about the term “Elm style”, but I suppose you mean graphical UIs with the Elm architecture in the background?

2 Likes
  • With LLM’s, boilerplate code that formats & “pretty-prints” is cheaper than ever…
  • Thus, more than ever, “string formatting code” is spawning, and polluting domain logic
  • Ultimately, layoutz is just a tiny, declarative DSL to combat this

:+1:

How does the architecture compare to brick?

To me the entry points look quite similar.

Brick:

data App s e n =
    App { appDraw :: s -> [Widget n]
        , appChooseCursor :: s -> [CursorLocation n] -> Maybe (CursorLocation n)
        , appHandleEvent :: BrickEvent n e -> EventM n s ()
        , appStartEvent :: EventM n s ()
        , appAttrMap :: s -> AttrMap
        }

Layoutz:

data LayoutzApp state msg = LayoutzApp
  { appInit          :: (state, Cmd msg)                 -- ^ Initial state and startup commands
  , appUpdate        :: msg -> state -> (state, Cmd msg) -- ^ Update state with message, return new state and commands
  , appSubscriptions :: state -> Sub msg                 -- ^ Declare event subscriptions based on current state
  , appView          :: state -> L                       -- ^ Render state to UI
  }
1 Like

oh wow so cute! I was recently doing some Go and they have a neat TUI framework too:

2 Likes

Yep exactly, thx for taking a peek … Elm style as in TEA/(Model - Update - View) to (re)render frames

data LayoutzApp state msg = LayoutzApp
  { appInit          :: (state, Cmd msg)                 -- Initial state + startup command
  , appUpdate        :: msg -> state -> (state, Cmd msg) -- Pure state transitions
  , appSubscriptions :: state -> Sub msg                 -- Event sources
  , appView          :: state -> L                       -- Render to UI
  }

Hello - thx for taking a peek … true … the brick interface / entrypoint looks pretty “Elm”y at a glance

but the Brick event handler EventM is monadic - so you mutate state and do IO inline … layoutz keeps it in this sense “pure” …

you return a new State + Commands and the runtime handles side effects..

Tangentially related … cf. this Reddit answer on (Brick vs Layoutz)

1 Like