ui: Adds <StateChart />
component for wiring together Ember+XState
#7742
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new
<StateChart />
and related components (<Action />
and<Guard />
).The components themselves wire together XState and Ember so you can use XState's state charts within ember templates.
There are a few things that are possibly in flux here:
as |State Action Guard dispatch state|
API. We'll potentially move this to just a hash. I've also considered using an@id
and@for
to wire up<State @for="chartId" />
to its<StateChart @id="chartId" />
similar to HTML<input /><label />
combos. This is still under consideration and not likely to be decided until we finish current feature work.@xstate/fsm
library, as opposed to the main 12kb@xstate/xstate
library to save ourselves 11kb. This may change, but we have another service that implements the same thing using the main xstate library instead (it requires slightly less wiring to use, not PRed here to keep it out of our build). In the future it would be nice to offer both options, configurable viaember-cli-build
options. Again likely to be done following current feature work.Upcoming stateful components will make use of these above components.
We quibbled over writing some tests here, but there really isn't an awful lot to test, it just wires things in to XState, plus this is still potentially in a little flux. We hope to eventually use XState's model based testing features to help us to test the components that will use XState.