Skip to content

Hoon UI framework

Jump to bottom
lomder-librun edited this page Nov 7, 2022 · 6 revisions

Overview

Views and state should be separated, but easy to merge.

Rind: the view tree

Sap: the state tree

  • strictly typed
  • immutable tree
  • graph model
  • on-action functions can modify state
  • on-snapshot
  • on-update

Holium’s proposal for a UI framework in hoon starts with a new vane that defines a set of standards to implement a user-interface tree. That tree is broken down into two parts:

  • Rind: the view layer of the tree. It has a component renderer that manipulates a virtual DOM and renders the document after the Sap’s state transitions. It should map directly onto the data state tree, but is optional.

  • Sap: the data/state layer of the tree. It defines models that are used for view rendering and updating. Sap can be updated via client actions, remote actions, and passed gifts from other vanes. Sap also allows developers to write observable views on a base model. These views can transform base state for Rind, but some developers may elect to write Sap that others can pull into their UIs.

References

Alt description

Our proposal for a UI framework in hoon starts with a new vane that defines a set of standards to implement a user-interface tree. That tree is broken down into two parts:

  • An observable state tree: defines the data, shape, and exposes a tree of typed observables. It defines a model’s typed and observable view data. Any other app developer could consume these observables in their interfaces which could be written as a view tree or a standard web app.
  • An application view tree: maps to the same structure as the state tree. It is very important to allow view code to be written alongside state in hoon, but also excluded if a developer does not want to implement a UI. The application view tree consumes the observable leafs and nodes from the state tree.

Clone this wiki locally