Hacker News new | past | comments | ask | show | jobs | submit login

A few times I've seen someone on HN bring up the idea of using statecharts for UI implementation. Many years ago there was a book around this idea, but I wasn't able to get a copy before it became very rare.

"Constructing the User Interface with Statecharts" https://www.amazon.com/Constructing-User-Interface-Statechar...

I've always wondered if statcharts were a powerful enough abstraction to handle everything I needed, and would like to read more about its specific application to implementing UIs. Does anyone have any other references, books, etc?




For js there are various implementations including this one: https://xstate.js.org/docs/

Here is an article by the author of this library with some justification for the appropriateness of statecharts in UI construction: https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-...


It should be, please have a look at http://scion.scxml.io/tutorials/fundamentals It is a pretty faithful implementation of SCXML in js


I have been looking for that too and could not find much, at least not much that is available for free. That said, I give a series of example of miscellaneous complexity in Kingly documentation site (https://brucou.github.io/documentation/). Kingly is a state machine library that replicates pretty much the formalism of statechart, without its concurrency model (i.e. no parallel states). Interestingly the amazon book you quote is also recommending to make spare use of parallel states (if I remember well, it recommends to use it only at the top-level of the chart, and when possible not at all). Anyways, on the Kingly site, you will find the following examples: - a counter (yeah there is always a counter or hello world somewhere) - a keypad app (with Svelte) - a password meter (tells you if yuor password is strong enough) - a two-player chess game (with React) - an interface to an online movie database (with 7 different UI libraries, including Vue, React, Svelte, Ivi) - a wizard form (with cycle.js) - an implementation of suspense functionality (with Svelte) - an implementation of Conduit, a clone of Medium. Conduit is considered to be, like TodoMVC a benchmark of miscellaneous approaches to UI implementation, but for a real world complex application.

I also published an article on the subject on infoq: https://www.infoq.com/articles/robust-user-interfaces-with-s...

All of that may be useful to you, with the benefits that you won't have to make the examples, as I had to, to evaluate the applicability of the technique to UI implementation.

If there is anythign you do not understand let me know.


I came across a javascript implementation [1] and HN discussion from a year ago [2].

[1] https://github.com/davidkpiano/xstate

[2] https://news.ycombinator.com/item?id=17805950


They are not powerful enough to model complex UIs. In terms of expressiveness, state machines are equivalent to regular expressions. That's why I find the title quite misleading. They may be useful to some extent for very simple UIs (for instance, Siemens Mobile has used them to model mobile phone (app) UIs).


Statecharts _builds upon_ state machines, but is a more powerful language to model a system's state than FSMs or regular expressions. There's a good explanation here [1].

1: https://stackoverflow.com/a/40679958/855105


What's their expressiveness? I always thought the nesting could be "flattened", so it wouldn't really make a difference?


Flattening the nested states would produce an explosion of states. This page describes how Statecharts avoids that [1].

In regard to expressivity, specially compared with FSM, a thorough description can be find in the paper "On Visual Formalisms" [2]. I copy some points here for convenience:

...people working on the design of really complex systems have all but given up on the use of conventional FSMs and their state diagrams for several reasons

(1) State diagrams are “flat.” They provide no natural notion of depth, hierarchy, or modularity + orthogonality + broadcast communication.

(2) State diagrams are uneconomical when it comes to transitions [...] resulting in an unnecessary multitude of arrows.

(3) State diagrams are [...] infeasible: as the system under description grows linearly, the number of states grows exponentially.

(4) State diagrams are inherently sequential in nature and do not cater for concurrency in a natural way.

1: https://statecharts.github.io/state-machine-state-explosion....

2: http://www.dcs.ed.ac.uk/home/kxt/on_visual_formalisms.pdf


State charts have parallel states, which require an exponential number of states with a finite state machine. And it supports history—returning to a container state can return to the last entered state in that container, whichever it was—I’m not sure if finite state machines can support that or not. Maybe they can, but again, it would vastly explode the state space.


State machines are a generic term. You will find here the different kinds of state machines, with varying expressive power that are used in computer science and actuak programming: https://github.com/achou11/state-machines

In any case, keep in mind that Turing machines are (extended) state machines (albeit with infinite memory) so the expressive power of state machine is at least anything computable (sequentially - turing machine is a model of sequential computation).


Statecharts are not the same as simple Finite State Machines.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: