As any UI framework, Humble UI needs some story for state management. Examples include:

• Same component, different state/detail (another fill color, another text).
• Component hierarchy changes dynamically (new item added, new label appears, switching to a different tab).
• Internal component state (button hover, cursor position in text field, etc).

Some intentionally vague constraints:

• Be able to react (subscribe) to changes in outside world.
• Components need inner state (e.g. text-field needs to track cursor position etc).
• Don’t lose state with parts that don’t change (e.g. if button or text-field is recreated in the same place with same identity, it should transparently keep its hover/focused/cursor position state).

State management is tied to component syntax, so we are trying to figure out both at the same time.

• Ability to query rendered tree

And some desirable properties:

• Minimize component trashing/recreation as much as possible.
• Use plain Clojure for conditional logic in rendering logic.
• Being able to plug in custom storages like DataScript, at least for model state.

Let’s see how these problems are addressed in different existing solutions.

Humble UI’s current state

Component hierarchies in Humble UI are mostly static. That means your whole app is a value, not a function. You define it with def, not defn:

(def app
  (ui/center
    (ui/label "Hello, world")))

When you render it or handle an event, one and only instance handles each render and measure and on-event.

The downside of this approach is, well, it’s static. You can’t change your UI. At all. It react to window resize because size constraint is an input parameter to draw method but that’s about it.