Switch Angular for XState

[sync-by-unito]

Goodbye Angular! We will make an XState & LitElement version of the demo app.

This issue will be very similar to the switch from platform-public to ui-transfer, so definitely take a look at the demo machine and demo (root) component there, and how all the XState parts match with the Angular app in platform-public. In short, the following guidelines can be followed.

• The Angular component itself (script, html & css together) becomes an (Rx)LitElement that
  • creates and interprets a machine,
  • subscribes to the interpreted machine (state) and its necessary context,
  • uses this context to render a LitElement template (based on the home component's html),
  • listens to HTML Events of the (sub)components in the template, and
  • translates them to XState events to the machine.
• The Angular state becomes the context of the machine, with
  • the initial state being set in the component when it creates the machine, and
  • the reducers being translated to XState assign actions.
• The Angular actions become XState events, which consist of
  • an enumeration of their labels,
  • classes which define their payload, and
  • a union type of those classes.
• The Angular effects remain functions, called services, which
  • are almost the same code, starting after their current Angular ofType operator,
  • take an XState context and event as input, and
  • end with a map to an XState event for the machine.
• The real creativity lies in defining the XState states of the machine:
  • Define an enumeration of states ("toestanden", "situaties") the machine can be in.
  • Make a union type of objects for every state, in which you restrict the context in those states, for example by making some optional properties mandatory. For this you can add interfaces that extend the context.
  • Add a boilerplate XState state schema, just because we sometimes need it.
• Finally, create a machine configuration, with for every state:
  • an invoke block with a service function as src, if needed, and
  • an on block with a target and optional actions for certain events.

NOTE: The SemCom demo contains an app component and a home component. The app component only really adds the authentication, so we mostly need to translate the home component as main demo component. The authentication part can then be added to the new demo component and machine using the ui-transfer parts exactly like in the ui-tranfer demo.

When in doubt, always look back to the ui-tranfer demo, and don't hesitate to ask for help.

┆Issue is synchronized with this Wrike Task by Unito

[woutermont]

Nice work!