XState at it's core is a configuration object and an interpretter for that object (to create the actual instance of that machine configuration).
This should not change. Instead, a abstraction on top of this to make the configuration easier to discover and learn is what I propose.
Make it easier to discover and learn XState through a highly typed, conversational API for generating state machine configurations.
I see there being two approaches for this using the builder pattern:
- The builder pattern, using a builder class/object to compose a state machine configuration, to be passed to the interpretter:
- Through strict dot-chaining, with a proper fluent interface (get, set, add, remove)
- Through composition, using multiple fluent assertions
None of this should be required -- it should be a builder class/object implemented separately that simply outputs the valid object configuration.
Resolutions should be lazy -- not evaluated until interpretations are run. This allows architecture that allows one setter to call a getter for something that isn't technically set if you are reading the code procedurally. (e.g, calling machine.getState()) on a later defined state.
Dot chaining is totally optional. The logic can be written as statement per line.