- Best practices - Debugging, Testing
- Also: With nested machines
- Non-deterministic random state possibility
- Light switch: On 'on', 50% chance to break next time (final)
- Self-transitioning state loop
- Wait for data, get data, wait again (for more), ... (simple concat output)
- Shield concept
- States : Off, On
- Transitions : Charging, Shutting down, Depleting
- Properties : Energy, Runtime/Duration (if on)
- Guards : Time left?, Depleted?
- Loops : On (Deplete)
- Actions : Deplete (if running, if requested by other entity, ...)
- Internal/External property changes
- Self-modifying state capability?
- Interactions : Can be depleted by () ...
- Aka: Side effects with other entities
- Similar to guards (or same?)
- How to create UI from diagrams only?
- Do they still need 'old fashioned' booleans for display conditions?
Use basic diagrams from 'XState' tutorial and re-create for own demo project.
- Design ship/shield concept (Official notation / UML)
- Add: Timeout (e.g. shield on automatically turns off after given time)
- Add: Guard (e.g. shield can be used max N times)
- Nested/parallel state machines (Robot: via invoke)?
- Complex to setup, even harder to debug/maintain - Best practices?
- Timed/Async state machines (Delay in transition, e.g. timeout)
- Can be done with promises
- Re-Build 'Ship + Shield' state machines
- Test: Actions (entry, transition, exit)
- Test: Compound/Hierarchical/Nested states
- External triggers (here: Global state switch via target)
- https://xstate.js.org/docs/guides/hierarchical.html
- Test: Parallel/Orthogonal states
- Test: History state
- Test: Delay/Timed/Async
- Automatic trigger?
- Test: Final state
- Simply move to an empty state that doesn't do anything else