UI = f(statesⁿ)
Modern UI work is framed as “UI = f(state)”, but developers argue that real applications—from web frontends to games—expose far more intertwined and hidden state than most models acknowledge. Commenters trade experiences with state machines, event streams, and deterministic game logic, debate how strictly to “make illegal states unrepresentable,” and highlight how tools like React, LiveView-style servers, or XState help tame complexity while still leaving gaps around syncing, animation, and multi-client behavior. Many see game development and formal state modeling as valuable practice for understanding these problems more deeply.
Game development and state modeling
- Several commenters advocate building simple games (e.g., solitaire, basic action games) to internalize that every visual possibility must exist in state somewhere.
- Even “simple” games quickly reveal far more state than initial diagrams suggest, especially with networking, cheating prevention, and replay/determinism.
- Complex board/card games (e.g., Wingspan, Magic: The Gathering) are seen as intimidating; people cite state machines, event-driven programming, stacks, and rule documents as tools to understand and model such systems.
- There is debate over how achievable deterministic networking is, given floating point behavior, chaos-like divergence, and platform differences; lockstep approaches are seen as hard but possible.
UI = f(state): benefits and limits
- Many agree that, in principle, the view is a pure function of state; games, replay systems, and dev/debug views are given as strong evidence.
- Others stress that “state” must include intermediate/UI-only state: partial form input, validation errors, loading flags, animation progress, etc.
- Overzealous “illegal states are unrepresentable” can harm UX (e.g., yelling about invalid email while typing); some argue useful states should not be modeled as illegal.
- A clearer separation is suggested between:
- state of the domain (validated data),
- state of the UI widget (what user is doing now),
- and the mapping between them.
Events, actions, and state machines
- Some propose thinking in terms of event streams:
state = reduce(state, event)andview = fn(state), with handlers dispatching events instead of mutating directly. - Others phrase it as
view, effects = fn(state, events)or action-centric models; critics note this usually reduces back to a state machine formulation. - State machines and tools/libraries for them are repeatedly recommended as a way to tame complexity.
Frontend complexity and architecture
- Browser apps are described as multiple local event loops plus remote/distributed systems, with weak, glue-heavy tooling compared to backend ecosystems.
- Frameworks like React are viewed as good at “state → DOM” but not responsible for full data-sync problems (realtime, offline, collaboration); other tools (queries, sync layers) fill gaps, often incoherently.
- Some advocate server-centric/liveview-style approaches, keeping most state and rendering on the server to simplify reasoning.
- Loading/fetching is highlighted as multi-state (initial load vs refresh vs append), and libraries that distinguish “loading” from “fetching” are praised.
Animations, transitions, and implicit state
- Transitions/animations challenge the naïve “UI = f(state” view when data changes before animations finish.
- Suggested fixes: treat animation status/progress as explicit state, or rely on platform-level declarative animation while keeping start/end states in application state.
- Overall, consensus leans toward: “it’s all state,” but some of it is implicit or handled by the platform.