The behaviour every screen implements — the LiveView half of Atui.

A view is a pure function of its own state: mount/1 builds that state, render/2 turns it into cells, and the callbacks return a new state plus an optional instruction to the runtime. Views never touch the terminal, which is what makes them testable — render/2 returns an Atui.Screen you can assert on without a tty in sight.

Callback replies

• {:ok, state} — carry on with new state
• {:pass, state} — this key was not mine; let the focused view have it
• {:push, module, opts, state} — stack another view on top (a popup)
• {:pop, state} — close this view and return to the one below
• {:halt, state} — quit the application

Stacked, or tiled

The runtime stacks views: a {:push, module, opts, state} reply draws the new view over what is below it, which is what a popup wants. For several views visible at once — tiled, each with its own ticker — a view holds an Atui.Panes in its state instead and becomes their container.

Keys, and who gets them

The root view — the one the application started with — sees every key first, so global keys like quit live in one place. It answers {:pass, state} for the keys it does not claim, and those go on to the view with focus, which is the topmost one. That is the default reply, so a view that says nothing about a key never swallows it.

Ticks

A view that wants a clock says how often in tick_interval/1; the runtime gives it a timer of its own and calls handle_tick/2 with that view's own count. Views without an interval never tick, and a slow view does not drag on a fast one.

Example

defmodule MyView do
  use Atui.View

  def mount(_opts), do: {:ok, %{count: 0}}

  def tick_interval(_state), do: 1_000

  def handle_key({:char, "q"}, state), do: {:halt, state}
  def handle_key(_key, state), do: {:pass, state}

  def render(state, rect) do
    Atui.Screen.new(rect.width, rect.height)
    |> Atui.Screen.box(rect, title: " demo ")
    |> Atui.Screen.put_lines_centered(rect, ["count: #{state.count}"])
  end
end