Refactor Launch form to use a state machine

[schottra]

This migrates the state representations for LaunchWorkflowForm into a xstate state machine. Previously, a lot of logic and context variables were store in useLaunchWorkflowFormState. Now, all of the states in the flow are represented in launchMachine, which is consumed by the state hook.

The machine uses a handful of services to do the async work. These are provided by the state hook.

I also moved the state management for the workflow/launch plan selectors into a separate state hook. This is in preparation for making the launch form state generic enough to handle either a workflow or task as a source.

The net result of this should be no change in functionality.

Note: There are some TODOs left on this branch. This PR is against a feature branch, and I intend to address them in a follow-up PR.

• Added launchMachine, which includes state definitions for schema, context, events for the whole launch flow. It also exports a machine config and a machine instance to be consumed by an interpreter.
• Moved most of the context variables and state management out of useLaunchWorkflowFormState. It now only contains the services used by the state machine for loading workflows, launch plans, and inputs. It also wires the state machine context into a child instance of a useWorkflowSourceSelectorState hook.
• Added useWorkflowSourceStateSelector hook, which translates between state machine context and the props/states needed for our SearchableSelector component.
• Updated LaunchWorkflowForm to use state-matching for conditional rendering of elements, and to consume the various context variables from our state machine.
• Added a common config for state machines. For now it just controls the devTools option, which should be true in development.
• Updated xstate/react to fix an issue with typings on useMachine

[codecov-commenter]

Codecov Report

Merging #99 into single-task-execution will increase coverage by 0.22%.
The diff coverage is 92.38%.

@@                    Coverage Diff                    @@
##           single-task-execution      #99      +/-   ##
=========================================================
+ Coverage                  67.49%   67.71%   +0.22%     
=========================================================
  Files                        372      374       +2     
  Lines                       6030     6078      +48     
  Branches                     945      947       +2     
=========================================================
+ Hits                        4070     4116      +46     
- Misses                      1960     1962       +2     

Impacted Files	Coverage Δ
src/components/Launch/LaunchWorkflowForm/types.ts	100.00% <ø> (ø)
...ponents/Launch/LaunchWorkflowForm/launchMachine.ts	75.51% <75.51%> (ø)
...h/LaunchWorkflowForm/useLaunchWorkflowFormState.ts	96.03% <96.29%> (+0.86%)	⬆️
...s/Launch/LaunchWorkflowForm/LaunchWorkflowForm.tsx	100.00% <100.00%> (ø)
...unchWorkflowForm/useWorkflowSourceSelectorState.ts	100.00% <100.00%> (ø)
src/components/common/constants.ts	100.00% <100.00%> (ø)
src/components/hooks/useFetchableData.ts	92.85% <100.00%> (ø)
src/components/hooks/useQueryState.ts	100.00% <100.00%> (ø)
src/components/hooks/useWorkflow.ts	42.85% <0.00%> (-57.15%)	⬇️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 38eab6d...16861d0. Read the comment docs.

[BobNisco]

I really like the approach of leveraging xstate more heavily!

[BobNisco]

Is there a way we can cut back on the use of casting? I was looking at the docs for xstate and I understand they don't have 100% perfect typing throughout, but I was curious if there was anyway to use type narrowing on the event passed in here or something?

[schottra]

I suspected you might bring this up :-).

I tried several approaches. I think the only real way to get solid type support is to use inline functions in the machine config. That didn't fully solve the problem and it's specifically recommend against by the documentation. So my compromise was to at least narrow things down by individually defining the events I was casting to so that in the context of the action we know what the shape of the data payload should look like.

I had a similar problem with the services below here. I could not find a way with the current type definitions to make the return types of the services strongly types. At best, they will be Promise<any>. That means that the implementations that I provide when I interpret this machine in my react hook have no way of being checked that they are returning a value with the correct shape, property names, etc.

The good news is that when the actions and services don't do what is expected, the tests will blow up. I spent a fair chunk of time getting tests working again, and some of that was finding places where actions/services were returning or expecting the wrong type. So I think for now, tests and runtime checking will be the best we can do.

I have two additional enhancements in mind for a follow-up PR:

1. Look into model-based testing for the machine. This should ensure that all machine states are reachable, that the rendered components look correct when we reach each state, and should fully exercise all of the actions/services. That should be a good signal for when things change and our typing isn't able to warn us at compile time.
2. Some people in the community have proposed workarounds involving runtime checks that are type guards. Basically, that we should be able to test the payload sent to the action and so a is SelectWorkflowVersionEvent. That won't help catch errors at compile-time though.

[BobNisco]

I guess I really am that predictable that I'd bring up types in a PR 😆

Sounds good, I certainly have spent less time with xstate than you have, so thanks for the thoughtful comments and I'm glad we have validation here in the form of tests!