Skip to content

Instantly share code, notes, and snippets.

View giannissc's full-sized avatar

John Skottis giannissc

  • Edinburgh, United Kingdom
  • 03:03 (UTC +01:00)
View GitHub Profile
@giannissc
giannissc / state-management.md
Last active February 24, 2024 12:23
State Management Patterns (and the Problems they Address) in Druid and Xilem

Types of State

  • Global Scope State = Application Data or Model
  • Local Scope State = UI State / Empemeral State (e.g. animation progress)
  • Inherited Scope State = Shared UI State / Ambient State (e.g. month selection in calendar element)
  • Distributed State (e.g. tab selection shared by tab bar and a tab grid that live in different parts of the view tree)
  • Transient State/Impulse Response (e.g. a button is pressed and a side bar is revealed)

Generic State Access Patterns (aka Global State)

  • Subset: Callback or Adapt
  • Descendent: Lens or Adapt

UX Notes:

General Visuals

  • The current state/value of a widget should be obvious/visible.
  • If the value doesn't fit the last digit should be faded to indicate that the value shown is only partial. A good heuristic would be to choose a size that is large enough to fit 3 digit numbers (e.g. selecting a value between 0-100)
  • Expand the label when the user is interacting with the widget.
  • The the widget's state/value should always be visible, move the location of the label if necessary (e.g. when pointer is interacting with the widget)
  • A widget should optionally provide an indication of the min/max boundaries, where relevant.
  • The slider should optionally provide an indication of intermediate values (e.g. axis ticks) between the min/max boundaries, where relevant.
  • UI elements that are used for fine control (e.g. knobs) should be big enough to make them easy to grab.
  • For widgets with a single functionality the entire widget's area should optionally be wired to trigger the widget's action.

General

  • Event and Lifecycle are propagated down the entire tree but if every single events was processed by every widget that would cause performance issues.
  • The mechanism which decides which events and lifecycles will be propagated to which parts of the tree is the Pod
  • Some events are global (e.g. WindowSize) and are handled directly by the Pod and some are local and targeted to specific subset of widgets in the tree (e.g.MouseMove).
  • Targeted events are controlled by the IS_DISABLED, IS_HANDLED, HAS_ACTIVE, IS_HOT, and HAS_FOCUS flags.

Event Handling Infrastructure

  • The IS_HANDLED flag is set to false at the root of the tree by the Pod
  • The widget that processes the event must set the IS_HANDLED flag through its context.
  • The IS_HANDLED flag applies to keyboard and mouse events.
@giannissc
giannissc / xilem-architecture-overview.md
Last active April 23, 2024 06:15
Xilem Architecture Overview

There are four user levels to using a GUI framework:

  1. View composition
  2. Custom interactions
  3. Custom widgets
  4. Framework Development

xilem-architecture-overview

View composition

xilem-architecture-view-composition