R22 Fast XState

npm i fast-xstate XState interpreter with pure unadultered thread hogging speed

Philosophy

The XState interpreter simply determines what order to call the user supplied code in, passing context between them all, in response to external events being inserted. This should be an extremely fast and lightweight process, but the current XState implementation carries significant overhead for high performance uses.

Debugging these functions is also difficult as seeing the state of the machine during previous states is hard, and with transient states is near impossible. We need a system that lets us use traditional debugging tools to quickly and clearly see what are the problems with our user supplied code, and in what order things have been called.

Background

Over the past 18 months, XState has served us immensely well.

However, we have found the implementation lacking for our admitedly very specific needs, which are:

1. As fast as possible execution
2. Tracing by stepping thru all transitions, including transient transitions

When we attempt to reuse the code of the current XState implementation, we are surpised that:

1. Some of the code files are large, making it difficult to decipher
2. None of XState seems to be written in XState

For our application, which is a blockchain that is written almost entirely using XState to manage the complexity of the project, we also have the ability to run XState machines inside of the blockchain itself.

This all begs the question: Can a small core of XState functionality be used to write all the extended functionality of XState in the XState language itself ?

Benefits are:

1. Smaller core code
2. Implementation can leverage the same tools XState applications do, such as visualization, testing
3. Contributors to the project, who will most likely be using XState for their own projects, will immediately understand how the system works
4. Possibly greater speed, with configurable thread hogging capability, when raw speed matters
5. All the tools of XState can be brought to bear on the XState project itself
6. writing the core and using XState become close to the same thing, meaning core developer time is spent more on the usage of XState, making them heavy power users, rather than two separate software disciplines taking place, with core more focused on conventional development, and users more focused on XState language
7. In the visual debugger, can present the underlying state machines, so users can understand what is happening under the hood, and can express bugs easier
8. The mere fact that it runs proves the utility of XState and the correctness of the implementation
9. Dicussion can focus more on what is the best statechart for processing the Xstate language ?
10. A degree of self provability - self proving that complex tasks can be handled, that the tooling and architectural skills are present within the process to use it for complex things
11. Add XState to the list of projects using XState - this is not true currently and it should be the largest user of its own produce

Features provided by a higher order state chart

The HOSC expands on the features of the core by running at the start and at every transition, in effect decorating the core behaviour. Seeing statecharts visually is about the most illuminating thing a programmer could hope for, and so by jumping into statechart land as early as possible, we can gain these benefits for the majority of the XState codebase.

1. invoke
2. parallel states
3. Format checking of machine and config
4. Actors
5. Error checking and handling
6. Transformation of shorthand expressions into core format
7. History
8. Jumping across states using id's
9. Statecharts ? Use core for only flat state machines ?

Interpreter state chart

This statechart calls the HOSC to do pure transition functions, then it takes the result and executes all the actions, updating the context.

1. Timers
2. start, stop, pause of running interpreter
3. receiving external events

Could the core be a statechart too ?

Transition to next node, resolve current node, then lob up an action to self to cause the processing of each step ?

In effect, there would be no single program that could execute the core statechart, just something to start the operation, ways to process each node, then actions send to self to move the system forwards.

Minimum subset of features required to implement all other features

1. receieve action
2. always transition
3. conditional transition
4. transition actions
5. single dimensional transitions With these features, can write a statechart that when executed

Debugging features

1. Each transition, along with exec() to call all functions, should contain a list of function names in the order they will be called in, so users can see what order their code will be called in each transition
2. Debugging for each piece of user code, where the call params and output result can be traced
3. each subsequent call to exec actually takes place within the last one, so debugger can walk the stack to see values of execution